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Abstract 

This  reseeirch  refined  the  visual  presentation  and  usability  of  a  previously  developed 
visual  interface  for  a  domain-oriented  apphcation  composition  and  generation  system.  The 
refined  visual  interface  incorporated  domain-specific  bit-mapped  graphics  and  sophisti¬ 
cated  user  interface  design  concepts  to  reduce  user  workload.  User  workload  was  reduced 
through  object  layout,  window  design,  and  color  utilization  techniques;  by  combining  repet¬ 
itive  procedures  into  single  commands;  and  reusing,  rather  than  recreating,  composition 
information  throughout  the  apphcation  composition  process.  The  Software  Refinery  envi¬ 
ronment,  including  its  graphical  interface  tool  iNTERViSTA,  was  used  to  develop  techniques 
for  visuahzing  and  mzuaipulating  objects  contained  in  a  formal  object  base.  INTERVISTA 
was  supplemented  with  graphical  routines  provided  by  Common  Windows,  a  Lisp-based 
graphical  environment  that  serves  as  the  foimdation  for  INTERVISTA.  The  interface  was 
formally  vzdidated  with  a  well-understood  apphcation  domain,  digital  logic-circuits,  and 
users  of  the  interface  were  polled  to  ascertain  the  subjective  usabihty  of  the  interface.  A 
comparative  analysis  of  the  apphcation  composition  process  with  the  previous  visual  in- 
terfa.ce  was  conducted  to  quantify  the  workload  reduction  reahzed  by  the  new  interfax:e. 
Workload  was  measured  as  the  number  of  user  interactions  (mouse  or  keyboard)  required 
to  compose  an  apphcation.  On  average,  apphcation  composition  effort  weis  reduced  44.0% 
for  the  test  cases. 
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Developing  a  Sophisticated  User  Interface  to  Support 
Domain-Oriented  Application  Composition 
and  Generation  Systems 


I.  Introduction 

1.1  Background 

As  quality  computer  hardware  becomes  more  available  and  affordable,  computer 
users  are  demanding  more  powerful,  high  quality,  affordable  software.  The  principles  of 
software  development  are  undergoing  substcmtial  evolution  as  software  engineers  and  pro¬ 
grammers  endeavor  to  comply  with  the  demand.  Software  engineers  are  embracing  tradi¬ 
tional  engineering  preictices  by  introducing  the  concepts  of  reusable  software  components, 
object-oriented  designs,  and  application  domain-specific  models.  The  destiny  of  software 
development  is  to  evolve  from  a  hamd-crafted  art  into  a  true  engineering  discipline.  As 
with  other  engineering  disciplines,  software  engineers  must  develop  understandable  and 
verifiable  components  that  can  be  combined  into  a  cohesive  whole,  often  by  the  users  of 
a  software  system.  Essentially,  in  the  future  software  engineers  will  deliver  the  knowl¬ 
edge  -  domciin-specific  knowledge  -  about  how  to  generate  softweure,  rather  than  delivering 
software  itself  (16:73).  The  software  generation  capability  will  be  delivered  in  the  form 
of  program  composition  environments  or  application  generators.  A  notional  view  of  a 
domeun-oriented  application  composition  environment  is  shown  in  Figure  1.1. 


Figure  1.1  Domain-Oriented  Application  Composition  Environment 
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The  Knowledge-Based  Software  Engineering  (KBSE)  research  group  at  the  Air  Force 
Institute  of  Technology  (AFIT)  continues  to  conduct  research  into  the  VEurious  aspects 
of  domain-oriented  application  composition  shown  in  Figure  1.1.  A  protot3^e  domain- 
oriented  application  composition  system  was  the  subject  of  research  by  the  KBSE  group. 
The  system,  called  Architect,  was  developed  by  Anderson  and  Randour  (1,  22)  and  has 
subsequently  imdergone  evolutionary  development.  Architect  runs  within  the  Software 
Refinery^^  development  environment,  centered  aroimd  a  Lisp-based  specification  language 
called  Refine.  Architect  provides  an  application  specialist  (the  intended  user)  with  the 
mezms  to  compose  applications  within  specific  domains.  Conceptually,  a  user  identifies 
a  validated  requirement  to  an  analyst  who  develops  an  operational  concept  for  a  sys¬ 
tem  to  fulfill  the  requirement.  The  concept  is  then  broken  into  software  jind  hardware 
subsystems.  Then,  based  on  detailed  knowledge  of  the  target  system  and  operational  en¬ 
vironment  provided  by  a  domsun  engineer,  releveint  software  components  are  mapped  into 
a  domain  model  and  a  formed  object  or  technology  base  by  a  software  engineer.  The  user, 
or  application  specialist,  manipulates  the  domEun  model  to  develop  a  prelimineiry  software 
specification  within  Architect.  The  specification  ceui  then  be  compiled,  and  the  resultEmt 
code  can  be  “executed”  to  simulate  system  operation.  The  execution  is  monitored  for  de¬ 
sired  functionEdity  of  the  “specified  system.”  The  development/compilation/executioncEin 
be  re-Ew:complished  imtil  the  specification’s  behavior  mirrors  the  system’s  desired  behavior. 
A  formal  specification  csin  then  be  generated  Euad  eventusdly  translated  into  a  deliverable 
softwEire  application  in  Ada,  C,  or  Euiother  language. 

The  Architect  system  development  process  briefly  described  above  ceui  be  quite  in¬ 
volved  and  complex.  A  rudimentary  visuEd  interfEice  was  developed  to  replEw;e  Architect’s 
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original  text-based  command  line  interface,  thus  making  system  use  significantly  easier 
(33).  The  visual  system,  called  Architect  Visuad  System  Interface  (AVSI),  adlows  the  ap*- 
plication  specialist  to  “see”  the  application  on  the  screen  rather  than  having  to  visualize  it 
in  his  head  and  to  manipulate  it  as  a  graphical  abstraction.  Figure  1.2  shows  the  relation¬ 
ship  between  AVSI  and  the  other  components  of  Architect.  AVSI  is  an  object-oriented, 
direct  manipulation  (DM)  interface.  The  term  “object-oriented  DM”  refers  to  a  class  of 
interf8ices  that  rely  on  “concrete  and  visible  objects  [icons]  .  .  .  where  the  key  activity 
is  visibly  moving  objects  by  pointing  at  them”  (30:365).  Although  AVSI  was  a  significant 
achievement,  its  usefvilness  was  primarily  functional.  However,  the  manner  in  which  a  soft¬ 
ware  system  displays  information  to,  and  interfaces  with,  its  user  either  invites  errors  or 
helps  minimize  them  (8:95).  Therefore,  the  aesthetic  enhancement  and  usability,  as  well  as 
continued  functional  development,  of  the  Architect  user  interface  was  the  goal  of  this  thesis 
effort.  Readers  unfamiliar  with  the  basic  AVSI  eure  referred  to  Weide’s  thesis,  “Develop¬ 
ment  of  a  Visual  System  InterfEice  to  Support  a  Domain-oriented  Application  Composition 
System”  (33). 

1.2  Problem 

The  reason  for  using  a  graphical  interface  is  fairly  straightforwEurd.  Simply  put,  it 
cillows  the  application  specialist  to  interactively  peirticipate  in  the  application  development 
process  without  having  to  become  a  programmer  (35:78).  A  Graphical  User  Interface  (GUI) 
has  the  benefit  of  allowing  novices  to  learn  a  system’s  bsisic  functionzJity  quickly,  usuEdly 
through  a  demonstration  firom  a  more  experienced  user  (24).  It  can  display  information  in 
understandable  and  recognizable  desktop  “metaphors”  or  icons  representing  the  actions. 
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Figvire  1.2  Architect  with  AVSI 

procedures,  or  structure  of  the  underlying  code  and  objects  (6:67).  For  example,  a  folder 
icon  cem  represent  a  file  directory,  or  an  icon  designed  to  look  like  an  AND-gate  can 
represent  the  code  fragments  that  simulate  ein  AND-gate  object. 

AVSI  was  written  in  iNTERVISTA,  the  graphics  package  companion  to  REFINE.  Be¬ 
cause  Intervista  provides  the  means  to  visually  manipulate  the  Refine  object  base, 
AVSI  provided  the  application  specialist  significant  functional  power.  However,  the  graph¬ 
ical  >phistication  of  Intervista  is  limited.  In  order  to  make  Architect  a  “user  ftiendly” 
tool  for  the  application  specieJist,  AVSI  needed  aesthetic  enhancements. 

Intervista  allows  a  user  to  create  and  manipulate  four  basic  objects:  siufaces, 
windows,  links,  wd  icons.  A  surface  is  a  two-dimensionally  infinite  plane,  whose  origin  is 
at  (0,0),  that  serves  as  a  base  for  the  other  graphical  constructs.  A  window  is  a  rectangular 
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opening  that  exposes  a  part  of  the  surface.  A  window  is  also  called  a  viewport.  A  link  is  a 
line  (curved  or  straight,  dashed  or  solid)  that  is  the  visible  manifestation  of  a  connection 
between  two  icons.  An  icon  is  a  two-dimensional,  geometric  shape  that  represents  an 
object  in  the  REFINE  object  base.  Legal  shapes  for  cin  Intervista  icon  are  box,  ellipse, 
dijunond,  eind  text.  Size  and  height-width-ratio  can  be  adjusted  for  an  icon,  giving  some 
smzdl  variety  in  available  icons.  A  text  icon  is  simply  an  icon  label  without  the  icon. 

These  four  visual  objects,  and  a  fairly  robust  set  of  functions  to  manipulate  the 
objects,  are  the  extent  of  INTERVISTA ’s  graphical  sophistication.  With  these  graphical 
limitations  in  mind,  developing  AVSI II  (an  enhanced  AVSI)  offered  a  number  of  challenges. 
First,  AVSI  utilized  the  full  potential  of  Intervista’s  graphics.  To  be  effective,  AVSI 
IPs  graphical  metaphors,  used  to  represent  objects  in  an  application  domain,  had  to  be 
representative  of  the  domain  being  manipulated.  This  is  something  that  is  beyond  the 
Intervista  graphics  capability.  A  means  of  augmenting  INTERVISTA ’s  graphical  cap2«:ity 
was  required.  REFINE  and  INTERVISTA  are  implemented  in  Allegro  Common  Lisp,  ^uld 
several  graphicd  interface  development  p^K;kages  exist  for  Lisp-based  GUI’s.  Additioneilly, 
Intervista  is  built  on  top  of  Allegro  Common  Windows^",  an  interface  from  Lisp  to  the 
generail  window  system  resident  on  the  hardweure  system.  Common  Windows  provided  an 
easy  extension  to  INTERVISTA ’s  graphics. 

Selection  of  appropriate  metaphors  was  a  second  challenge.  Each  domain  model 
of  interest  requires  a  different  set  of  “representative”  icons.  Similarly,  a  particular  icon 
or  metaphor  might  not  be  appropriate  across  different  levels  of  abstraction  within  the 
seune  object  domain.  With  careful  design,  it  is  possible  to  represent  large  amounts  of 
information  without  creating  a  cluttered  display.  Iconic  design  and  ^^letaphoric  selection. 


as  well  as  spatial  relationships  and  screen  layout,  was  a  significant  portion  of  this  research 
effort. 

Lastly,  although  AVSI  provided  an  application  specialist  with  a  bro2ul  base  of  func¬ 
tionality,  some  of  the  processes  were  repetitive,  time  consiuning,  or  tedious.  The  challenge 
was  to  medce  AVSI  II  more  usable  without  changing,  or  at  the  least  degrading,  the  basic 
fimctionality  of  AVSI. 

In  order  to  meet  the  chzdlenges  described  above,  the  following  research  goals  and 
objectives  were  established: 

1.  Develop  a  set  of  domzun-specific  graphical  icons  (metaphors)  for  an  existing  Architect 
application  domain  and  integrating  the  graphics  into  AVSI  II’s  application  construc¬ 
tion  process. 

2.  Develop  the  means  for  domain  engineers  to  develop  and  incorporate  additional  iconic 
metaphor  sets  for  new  application  domains. 

3.  Redesign  the  update  algorithm  definition  process  to  eliminate  duplication  of  effort 
amd  tedium. 

4.  Redesign  the  import/export  connection  process  by  exploiting  the  domeun-specific 
graphics  to  meike  object  coimection  more  intuitive. 

5.  Support  the  visualization  needs  of  concurrent  research  activities. 

6.  Test  the  new  interface  and  quantify  AVSI  II’s  improvement  in  the  areas  of  usability 
emd  composition  effort  reduction. 
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1.3  Assumptions 


Several  assumptions  were  meide  for  the  development  of  AVSI.  Since  the  fimctioncility 
of  Architect  and  AVSI  were  validated  using  the  digital  logic-circuits  domain,  it  was  assumed 
that  the  domain  was  adequate  for  testing  and  validation  of  AVSI  II.  Additionally,  the  basic 
functionality  of  AVSI  was  considered  adequate  emd  no  significantly  new  capabilities  were 
developed.  Finally,  it  was  assumed  that  reuse  of  the  existing  AVSI  would  be  maximized 
to  maintain  compatibility  with  other  research  efforts  on  Architect  and  with  previously 
developed  applications.  As  such,  ReFINE  and  Intervista  were  the  primary  development 
packages  for  AVSI  II. 

1.4  Scope 

AVSI  II  was  intended  to  extend  the  graphical  sophistication  of  the  Architect  interface. 
Therefore,  no  significemtly  new  functioned  featvires  were  implemented.  The  scope  of  AVSI 
II  was  limited  to  enhemcement  of  the  visued  presentation  of  information  to  a  user  and 
simplification  of  the  application  specialist’s  design  effort.  AVSI  II  does  not  provide: 

•  Visual  support  to  the  semantic  check  process  or  the  application  execution.  These 
topics  are,  however,  logical  extensions  in  the  development  of  more  sophisticated  in¬ 
terfaces. 

•  More  than  rudimentary  support  for  an  Application  Executive.  Pull  support  of  time- 
driven  simulations  or  event-driven  simulations  was  not  incorporated  but  should  be  a 
topic  for  follow-on  research. 
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1.5  Sequence  of  Presentation 


The  remainder  of  this  thesis  is  organized  as  follows: 

Chapter  II  provides  a  review  of  current  literature  concerning  techniques  for  icon  and 
metaphor  design,  window  layout  considerations,  and  uses  of  color  in  user  interfaces.  A 
survey  of  Lisp-based  graphical  interface  software  packages  and  techniques  is  also  included. 

Chapter  III  illustrates  the  operational  concept  for  AVSI  11  by  tracing  through  the 
application  composition  process.  The  shortfalls  of  AVSI  are  analyzed  at  each  step,  and  the 
changes  implemented  in  AVSI  II  are  discussed. 

Chapter  IV  discusses  the  specifics  of  each  aspect  of  AVSI  U’s  design,  design  tradeoffs, 
and  implementation  details. 

Chapter  V  addresses  the  testing  and  validation  of  AVSI  II  and  presents  an  analysis 
of  its  capabilities. 

Chapter  VI  contains  conclusions  about  the  AVSI  II  research  effort  as  well  recom¬ 
mendations  for  future  research. 

Several  appendices  are  included  to  provide  eulditional  information  concerning  Archi¬ 
tect  and  AVSI  II.  Appendix  A  provides  a  s^unple  session  with  AVSI  II  wherein  an  appli¬ 
cation  from  the  digital  logic-circuits  domain  will  be  built.  Appendix  B  presents  detsdled 
instructions  for  a  domain  engineer  on  designing  and  building  a  set  of  iconic  metaphors 
compatible  with  AVSI  II  and  incorporating  them  into  the  Architect  system.  Appendix  C 
cont2uns  a  description  of  a  collection  of  general  metaphors  available  for  use  with  AVSI  II. 
Appendix  D  consists  of  a  list  of  the  files  required  to  run  AVSI  II  zmd  a  point  of  contact 
from  whom  to  acquire  the  REFINE  source  code  for  AVSI  II. 
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II.  Literature  Review 


2. 1  Introduction 

The  objective  of  this  literature  review  was  to  examine  relevant  issues  and  research 
in  the  areas  of  human-computer  interaction  and  specifically  address  the  issues  of  icon  and 
metaphor  design,  window  layout  considerations,  and  design  concerns  in  incorporating  color 
into  a  user  interface.  The  review  involved  an  extensive  gathering  of  data  and  em  evaluation 
of  that  data  in  the  context  of  applicability  of  the  information  and  techniques  to  the  AVSI 
II  design  effort.  Although  much  of  the  information  is  general  in  nattnre,  some  references 
were  found  that  addressed  specific  areas  of  the  AVSI  II  design.  Additionally,  several 
commercial  and  public-domain  Lisp-based  GUI  development  environments  and  graphical 
support  packages  were  reviewed  as  potential  augmentation  tools  for  iNTERViSTA. 

2.2  Icon  and  Metaphor  Design 

2.2.1  Icons  in  Everyday  Use.  Webster’s  New  Collegiate  Dictionary  defines  zm 
icon  as  “a  usually  pictori2d  representation:  IMAGE”  (19).  Although  icons  are  frequently 
associated  with  religious  imagery,  an  icon  is,  in  fact,  any  picture  or  symbol  used  to  represent 
another  object,  idea,  or  action.  Icons  have  infiltrated  almost  every  aspect  of  our  daily  lives, 
especially  as  a  result  of  attempts  to  communicate  across  the  barriers  of  leinguage.  A  cross 
has  been  an  iconic  representation  of  the  Christian  religion  for  almost  two  thousand  years; 
however,  there  are  many  examples  of  more  contemporary  icons.  Even  yoxmg  children 
recognize  a  man’s  or  woman’s  silhouette  as  representing  a  public  restroom,  a  circle  with  a 
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Figure  2.1  Contemporary  Icons 


bar  through  it  as  representing  “don’t,”  or  a  skull  eind  cross-bones  as  representing  poison 
(see  Figure  2.1). 

Perhaps  the  most  widespread  use  of  icons  is  in  highway  signs.  Figure  2.2  shows  some 
signs  that  convey  precise  messages  simply  through  their  shape  or  picture;  any  accompany¬ 
ing  text  is  usually  unnecessary.  This  capability  to  convey  meaning  is  reflective  of  Arend’s 
concept  of  a  “global  superiority”  visual  effect  (2).  The  global  superiority  effect  asserts  that 
global  features  like  shape,  size,  and  color  can  be  recognized  and  assimilated  faster  thsin 
features  like  lines  and  text.  In  other  words,  simple  pictures  with  one  or  two  distinctive 
features  make  effective  icons.  Nan  Shu  also  endorses  the  use  of  icons  by  stating  (25): 

•  Pictures  Eire  more  powerful  thEm  words  as  a  means  of  communication  because  they 
convey  more  mesming  in  a  more  concise  unit  of  expression. 

•  Pictures  Eiid  comprehension  Eind  remembering. 

•  Pictures  typicsdly  do  not  have  lEmguage  bEuriers.  Properly  designed  pictures  sure 
understood  by  people  regardless  of  their  native  lEuiguage. 

Given  the  extensive  use  of  icons  in  our  everyday  lives,  it  is  not  surprising  that  the 
computer  industry,  adways  looking  for  ways  to  appead  to  new  users  aind  cross  the  barriers 
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Figure  2.2  Highway  Icons 


of  command/programming  languages,  is  moving  away  from  complex  textual  descriptions 
and  comm2uids  zmd  toward  simpler,  more  easily  understood  iconic  interfaces. 

2.2.2  Icons  in  Computer  Use.  The  primeiry  goal  of  a  GUI  is  to  increase  human 
productivity  and  speed,  eind  to  reduce  hum2ui  error  ^lnd  fatigue.  In  Human- Computer 
Interface  Design  Guidelines,  Brown  notes  that  appropriately  applied  icons  and  symbols, 
directly  manipulatable  by  a  user  in  ways  an2dogous  to  reality,  can  help  the  user  maintain 
context  and  orientation  and  reduce  the  user’s  need  to  memorize  commands  and  syntax. 
More  importantly,  looking  at  and  working  with  pictures  is  more  frm  th2m  working  with  a 
screen  full  of  text.  Icons  can  be  more  effective  than  text  because  they  can  convey  a  large 
amount  of  information  in  little  space,  they  are  easily  lesurned  and  easily  remembered,  and 
they  are  more  universal  (3).  The  icons  2uid  symbols  on  a  display  Eire  frequently  referred 
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to  as  metaphors  because  of  the  designed  intention  of  using  them  to  represent  a  piece  of 
reality  in  an  abstract  way.  The  icon  or  metaphor  is  a  visual  representation  of  a  command, 
teisk,  method,  file,  object,  etc.  The  first  challenge  in  GUI  design  is,  therefore,  to  develop  a 
set  of  metaphors  appropriate  to  the  domain  of  interest. 

Determining  what  metaphor  to  use  as  an  icon  can  be  difficult.  The  key  to  developing 
a  useful  metaphor  is  to  exploit  a  user’s  knowledge  of  familiar  objects  in  a  domain.  Erickson 
recommends  looking  at  a  system’s  functionality  for  clues.  He  says  to  “note  what  metaphors 
are  already  implicit  in  the  problem  description  [domain]”  because  people  commonly  use 
metaphors  when  t<ilking  about  abstract  concepts,  and  “it’s  almost  certain  that  metaphors 
are  lurking  about  in  the  description  of  the  [system’s]  fimctionality”  (9:69). 

Mzmy  authors  have  attempted  to  describe  what  constitutes  a  good  icon  design.  Deb¬ 
orah  Mayhew  recommends  the  following  (18:316-330): 

•  Minimize  semantic  and  articulatory  distance, 

•  Provide  visual  feedback  for  icon  position,  selection,  and  movement, 

•  Choose  a  consistent  icon  scheme, 

•  Design  icons  to  be  concrete  emd  familiar, 

•  Design  icons  in  a  set  to  be  visually  and  conceptually  distinct, 

•  Avoid  excessive  detail  in  icon  design, 

•  Accompany  icons  with  neunes, 

•  Limit  the  number  of  icon  types  to  12  if  possible,  but  at  most  20. 
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Two  of  these  design  features  (i.e.,  provide  visual  feedb^u:k  and  name  the  icons)  are 
incorporated  into  AVSI’s  design. 

Sem2intic  distance  is  the  subjective  or  psychological  distance  between  the  user’s  in¬ 
tended  action  on  an  icon  and  the  operations  allowed  by  the  interface  to  be  performed 
on  the  icon.  Sememtic  distance  directly  applies  to  the  level  of  abstraction  represented  by 
the  GUI.  Articulatory  distance  refers  to  the  relationship  between  an  icon’s  shape  and  its 
meaming.  For  example,  representing  a  Nand-gate  with  an  icon  that  looks  like  a  bcLsebadl 
imposes  a  Icirge  articulatory  distance  on  the  metaphor. 

Ben  Shneiderman  recommends  many  of  the  same  guidelines,  but  adds  that  the  de¬ 
signer  should  (24:210): 

•  Meike  the  icon  stand  out  from  its  b2ickground, 

•  Ensure  the  harmoniousness  of  each  icon  as  a  member  of  a  feimily  of  icons. 

Mayhew’s  fifth  guideline  (i.e.,  design  icons  in  a  set  to  be  distinct)  8md  Shneidermem’s 
second  guideline  (i.e.,  ensure  the  harmony  of  each  icon  in  a  family)  relate  well.  Within  a 
specific  domeiin  (or  set  or  fzunily)  every  icon  must  be  distinct  and  recognizable  from  every 
other  icon,  but  they  must  all  relate  to  the  overall  domain.  A  paintbrush  would  be  out  of 
pleice  in  a  logic-circuits  dom2dn,  for  example. 

Ccirroll,  Mack,  ^lnd  Kellogg  state  that  developing  a  set  of  interface  metaphors,  or 
icons,  is  an  iterative  process  that  is  refined  over  time.  They  clmm  the  first  step  in  creating 
a  metaphor  set  is  to  generate  a  set  of  candidate  metaphors  and  develop  them  using  these 
ingredients: 
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•  User’s  experiences  with  other  systems  or  situations  similar  to  the  system  being  de¬ 
signed, 

•  User’s  knowledge,  perceptions,  tind  motivations, 

•  Sheer  invention. 

They  further  emphasize  that  they  know  of  no  formal  analysis  method  for  generating  useful 
metaphors  (6). 

Chang  goes  a  step  further  by  recommending  a  strategy  for  creating  visual  represen¬ 
tations  of  objects.  He  recommends  considering  the  following  factors  (7:69-70): 

•  Application  and  CulturjJ  Dependence:  Icons  typically  represent  a  class  of  objects 
rather  than  one  specific  instance.  Avoid  excessive  detail  and  reflect  the  semantic 
nature  of  an  object. 

•  E^lsy  Recognition:  An  icon  should  have  a  precise  meaning  that  is  easily  recognized 
once  identified.  Icons  do  not  have  to  be  read,  and  people  typically  do  not  read  words 
they  sire  famili2ir  with  anyway  (Note:  This  does  not  preclude  icon  labels).  There  are 
more  distinctively  shaped  pictures  than  words. 

•  Distinction  From  Other  Icons  Within  the  System:  An  icon  must  be  individually 
distinctive  and  should  use  a  distinguishing  feature  to  reflect  the  meaning  it  represents. 

•  Consistency  in  an  Environment:  Although  icons  should  be  distinctive,  they  should 
be  consistent  and  harmonious  within  a  system  or  domain. 

Erickson  describes  a  process  for  generating  interface  metaphors  which  consists  of  the 
following  fundeimenteil  steps  (9:68-72): 
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•  Determine  Functional  Definition:  It  is  necessary  to  understand  something  in  order  to 
develop  a  model/metaphor  for  it.  This  includes  what  it  looks  like,  how  it  functions, 
and  what  its  semantic  behavior  is. 

•  Identify  User’s  Problems:  Figure  out  what  information  about  an  object  is  important 
to  a  user  and  incorporate  the  information  into  the  icon. 

•  Generate  Metaphors:  Note  what  metaphors  are  already  implicit  in  the  problem  (or 
domain)  description.  Using  previously  identified  metaphors  can  aid  recognition  of 
the  icon. 

•  Evaluate  Interface  Metaphors:  Once  the  metaphors  have  been  developed,  evaluate 
their  accuracy  and  effectiveness  through  actual  use.  Allow  users  to  provide  feedback 
on  the  icon  design. 

2.3  Window  Design  and  Layout 

Thomas  Tullis  summmzes  the  importance  of  the  overall  window  design  and  layout. 
He  states  that  the  overeill  content  and  format  of  the  information  in  a  display  will  have  a 
substantial  imp2K:t  on  the  user’s  ability  to  interact  with  it.  He  asserts  that  if  a  system,  or 
interface,  does  not  present  the  information  that  a  user  needs  in  a  format  that  is  usable  and 
understandable,  the  user’s  performamce  may  be  degraded  or  he  may  decide  to  abandon  the 
system  (29).  Sever2d  other  authors  concur  with  the  sentiment  by  explsuning  that  increasing 
display  density  tends  to  decrease  overall  user  performance.  A  well  designed  display  (window 
or  set  of  windows)  should  display  all  the  information  needed  to  perform  a  given  task.  It 
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should  also  display  only  the  information  needed  to  perform  a  task;  additional  information 
may  confuse  a  user  and  distract  from  the  importance  of  the  required  information. 

Shneiderm2ui  contends  that  a  display  format  should  be  famili2ur  to  a  usei  and  should 
be  reflective  of  the  task  being  performed  with  the  data.  He  echoes  Tullis’s  concern  for 
localizing  relevant  information  to  a  single  display  by  stating  that  users  should  not  be 
required  to  remember  information  from  one  screen  for  use  in  another  screen  (24:79). 

Additionally,  ShneidermEin  advises  caution  in  designing  a  direct  manipulation  (DM) 
interface.  DM  designs  tend  to  consume  valuable  screen  space  Eind,  as  a  result,  valuable 
information  is  frequently  available  only  by  scrolling  or  opening  another  window.  For  ex¬ 
perienced  users  of  a  system,  a  tabular  display  is  often  preferable  to  a  graphiceil  display 
(24:205). 

2.4  Color  Usage 

The  use  of  color  in  a  computer  interface  can  be  separated  into  two  distinct  aspects. 
Color  can  be  part  of  the  information  in  the  window  (such  as  text  or  icons)  or  it  cein  be 
part  of  the  window  itself  (such  as  the  b£w:kground,  fraune,  title,  or  control  devices). 

Color  adds  an  entirely  new  dimension  to  a  GUI.  Color  is  easy  to  incorporate  into 
a  display  and,  subsequently,  eaisy  to  misuse.  The  conservative  use  of  color  Ccin  provide 
powerful  context  euid  content  cues  to  a  user,  while  a  busy  emd  overly  colorful  screen  may 
only  confuse  a  user  and  mask  the  import2ince  of  information. 
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There  is  an  abundance  of  information  relating  to  color  use  in  computer  displays,  and 
mamy  guidelines  have  been  developed.  Shneiderman  recommends  that  an  interface  designer 
(24:325-328): 

•  Use  color  conservatively, 

•  Limit  the  number  of  colors, 

•  Recognize  the  power  of  colors  as  a  coding  technique, 

•  Design  for  monochrome  first,  then  add  color  judiciously, 

•  Be  consistent  in  color  coding, 

•  Be  cilert  to  problems  with  color  pairings,  and 

•  Use  color  in  graphic  displays  for  greater  information  density. 

Mayhew  endorses  the  same  guidelines  but  adds  her  own  recommendations  (18:490-502): 

•  Be  consistent  with  color  associations  people  have  in  their  jobs  and  cultures, 

•  Limit  the  number  of  colors  to  between  four  and  eight, 

•  Choose  symbol  (icon)  and  backgroimd  color  combinations  carefully,  and 

•  Recognize  that  color  use  can  improve  user  satisfaction. 

Furthermore,  Brown  adds  the  following  design  considerations  (5:67-76): 

•  Use  color  to  highlight  or  emphasize, 

•  Do  not  use  color  to  compensate  for  a  poorly  formatted  display, 

•  Be  aweure  of  abnormad  color  vision, 
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•  Use  similar  colors  for  related  data,  and 


•  Use  contrasting  colors  to  distingviish  data. 

Several  items  above  refer  to  consistency  and  color  associations.  The  importance  of 
maintsdning  cultural  color  associations  needs  to  be  stressed.  Different  people  use  colors  to 
mean  different  things,  but  there  are  several  standard  associations.  For  example,  red  means 
stop,  hot,  or  danger;  blue  means  cold,  cool,  or  safe;  yellow  means  warm  or  caution;  and 
green  means  go.  Violating  these  and  other  color  associations  could  cause  confusion  for  the 
application  specialist. 

One  important  color  consideration  mentioned  above  is  color-blindness.  Studies  have 
shown  that  8%  of  men  and  0.5%  of  women  are  to  some  degree  color-vision  deficient,  par¬ 
ticularly  in  distinguishing  green  firom  red  (23:271).  This  fact  enforces  the  importance  of 
careful  color  use. 

Two  themes  recur  in  ecich  author’s  design  guidelines:  design  a  display  as  monochrome 
first  and  choose  appropriate  color  pairings.  Designing  a  monochrome  display  first  forces 
the  GUI  designer  to  ceirefully  consider  metaphor  choice  and  icon  shape  and  design,  as 
discussed  in  Section  2.2.2.  Color  C2ui  then  be  conservatively  emd  judiciously  added  to  a 
display.  Color  should  be  used  to  enheuace  a  GUI  and  highlight  or  emphasize  similarities 
and  differences.  It  is  important  to  note  that  not  all  computer  systems  eire  equipped  with 
a  color  display  capability  so  the  GUI  must  be  usable  without  color. 

Secondly,  care  must  be  taken  with  color  pairing,  or  the  choice  of  icon  aind  background 
colors.  Certain  color  combinations  are  compatible,  while  others  are  not.  Poor  color  pairing 
contributes  to  user  fatigue  and  difficulty  in  discriminating  among  icons.  Designers  should 
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use  high  contrast  color  combinations  to  indicate  differences  and  low  contrast  colors  to 
indicate  similarities.  Following  ^ure  some  examples  of  effective  color  combinations  (18:498): 


High  Contrast  Colors 


Low  Contrast  Colors 


Red  -  Cyan 

Blue  -  Yellow 

Green  -  Magenta 

Red  -  Green  -  Blue 

Red  -  Green  -  Blue  -  White 


Yellow  -  White 
Red  -  Magenta 
Yellow  -  Orange 
Red  -  Orange 
Blue  -  Cyan 


2.4- 1  Window  Color.  The  effect  of  color  on  the  usability  of  a  display  is  a  topic 
widely  discussed  in  the  literature:  however,  few  hard  facts  are  available.  Murch  presents 
data  from  a  study  in  which  16  participants  were  asked  to  select  the  best  and  worst  color 
combinations  for  text  and  lines  against  backgroimds.  The  data  was  collected  for  text 
and  thin  lines  (two  pixels  wide)  jmd  for  thick  lines  and  panels.  The  results  of  the  study 
are  shown  in  Tables  2.1  and  2.2.  Although  the  data-set  is  limited,  it  does  address  the 
importsmce  of  color  choice  for  foregroimd  and  background  colors  in  a  display  (21). 

2.4- 2  Icon  Color.  When  and  how  to  use  color  in  icons  are  also  considerations 
when  designing  an  interface.  Color  cem  create  strong  associations  when  used  in  conjunction 
with  certain  shapes  or  locations  (23:275).  One  effective  use  of  color  is  to  provide  a  user  with 
information  not  otherwise  available  in  the  display  or  to  redundantly  reinforce  information 
that  is  already  there.  However,  the  use  of  color  in  icon  design  is  not  discussed  as  extensively 
as  is  color  use  in  the  overall  display.  For  icons,  color  is  most  effective  as  a  highlight 
mechanism  or  as  a  method  to  convey  groupings  of  data.  Baecker  effectively  cautions 
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Table  2.1  Best  Color  Combinations  (21)  Table  2.2  Worst  Color  Combinations  (21) 
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against  the  overuse  of  color  by  admonishing  the  interface  designer  to  avoid  the  “fruit  salad” 
appeuance  that  can  be  caused  by  the  undisciplined  use  of  color  in  a  display  (4:304). 

2.5  Lisp-based  Graphics  Software 

2. 5. 1  Intbrvista  .  Intervista^^  is  a  Lisp-based  tool  that  allows  a  user  to  create 
interactive  user  interfaces  for  applications  written  in  REFINE.  iNTERVISTA  provides  tools 
for  constructing  diagrams,  pop-up  menus,  and  mouse-sensitive  text  windows.  Diagrams 
are  created  in  an  Intervista  window  using  icons  (boxes,  diamonds,  ellipses)  and  links 
(connections).  INTERVISTA  provides  the  user  with  a  capability  to  customize  diagrams 
by  altering  icon  shape,  size,  and  labels;  controlling  link  arrow-heads,  labeb,  and  type; 
and  adjusting  window  size  and  shape.  Pop-up  menus  can  be  single-item  or  multiple-item 
selections.  Text  windows  are  an  extension  of  the  REFINE  printer  and  cam  contain  regular 
or  mouse-sensitive  text.  INTERVISTA  is  a  commercial  product  sold  as  part  of  the  Software 
Refinery^^  specification  language  environment  by  Reasoning  Systems  Inc.  INTERVISTA  is 
built  on  top  of  Common  Windows,  the  underlying  window  system  (13).  Both  AVSI  amd 
AVSI II  are  written  in  INTERVISTA. 

2.5.2  Common  Windows.  Allegro  Common  Windows^^  provides  the  interfiw:e 
from  Lisp  to  the  general  window  system  supplied  with  the  haurdware.  Common  Windows 
(CW)  uses  the  X  window  system  amd  aK;ts  ais  a  front  end  to  Common  Lisp  X  interface 
(CLX).  CW  provides  the  capabilities  to  create  amd  manipulate  window  streams,  atctive- 
regions,  regions,  bitmaps,  bitmap-streams,  text  operations,  menus,  amd  more.  Multiple 
window  environments  amd  scrolling  aure  supported.  Graphics  options  include  bitmap  amd 
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color  manipulation.  Conunon  Windows  is  a  commercial  product  available  from  FVanz,  Inc. 

(10) 


2.5.3  CLX.  CLX  (Common  Lisp  X  interface)  provides  basic  Common  Lisp/X 
functionality.  Each  programming  language  must  have  a  specific  functional  interface  for 
using  the  X  protocol.  CLX  is  a  de  facto  standard  low-level  interface  to  X- Windows  for 
Common  Lisp.  CLX  is  a  set  of  data  types,  functions,  and  macros  that  allow  a  program  to 
interact  with  am  Xll  server.  (27) 

2.5.4  CLIM.  Common  Lisp  Interface  Manager  (CLIM)  is  a  high-level,  portable 
user  interface  management  system  toolkit.  It  provides  facilities  for  basic  windowing,  in¬ 
put,  output,  and  graphics  services.  Additionally,  it  provides  an  Applications  Programmer 
Interface  (API)  to  user  interface  facilities  for  the  Lisp  application  programmer.  It  uses 
the  services  of  the  host  machine’s  window  system  (i.e..  Motif  or  OpenLook)  to  integrate 
Lisp  applications  into  the  host’s  window  environment.  CLIM  has  the  flexibility  to  provide 
detailed,  low-level  user  control  of  interface  layout  as  well  as  high-level  automated  layout 
capability.  CLIM  is  commercial  software  developed  by  Symbolics.  (26) 


2.5.5  GINA.  The  following  description  is  extracted  from  the  Generic  IN teractive 
Application  (GINA)  user’s  manual  (20): 

GINA  is  an  object-oriented  application  framework  written  in  CommonLisp  and 
CLOS  [Common  Lisp  Object  System].  It  is  based  on  CLM,  an  interface  between 
CommonLisp  and  the  OSF/Motif  software.  The  Generic  INteractive  Applica¬ 
tion  is  executable  zmd  has  a  complete  graphical  user  interf2ice,  but  lacks  any 
application-specific  behavior.  Version  2.1  of  GINA  is  publicly  available  and 
includes  full  documentation.  It  nms  on  Allegro  or  Lucid  Common  Lisp  and  on 
Symbolics  Lisp  Machines.  A  version  of  GINA  for  C-h-h  is  also  available.  .  . 


CLM  is  a  language  binding  for  Common  Lisp  and  OSF/Motif.  It  consists  of 
a  Motif  daemon  and  a  Motif  server.  The  Motif  daemon  runs  on  an  arbitrary 
machine  in  the  network  and  listens  for  Lisp  processes  requesting  to  use  CLM. 
The  Motif  daemon  forks  Motif  server  processes  which  communicate  with  their 
Lisp  processes  over  a  TCP/IP  connection.  When  supported  by  the  Lisp  system, 
the  Motif  server  can  also  be  directly  forked  from  the  Lisp  process.  The  Motif 
server  offers  the  functionality  of  the  X  toolkit  and  the  convenience  functions  of 
OSF /Motif  on  a  network-transparent  TCP/IP  protocol.  A  package  of  Common 
Lisp  functions  provides  a  high-level  interface  to  this  protocol. 


GINA  and  CLM  are  available  free  via  zmonymous  ftp  from  ftp.gmd.de. 


2.5.6  CLUE.  The  Common  Lisp  User  Interface  Environment  (CLUE)  was  de¬ 
veloped  by  Texas  Instruments  Incorporated.  The  following  is  extracted  fr.nn  TI’s  CLUE 
documentation  (28): 

The  Common  Lisp  User  Interface  Environment  (CLUE)  is  a  portable  system 
for  user  interface  programming  in  Common  Lisp.  CLUE,  which  is  based  on 
the  X  Window  System  and  the  Common  Lisp  Object  System  (CLOS),  extends 
the  CLX  [Common  Lisp  X]  interface  to  provide  an  architectural  model  for 
the  construction  of  interj«:tive  Lisp  applications.  Modelled  on  the  Xt  toolkit 
librwy,  CLUE  could  be  described  as  a  translation  of  the  Xt  “intrinsics”  into 
the  domain  of  Common  Lisp  and  CLOS. 

CLUE  is  available  free  by  anonymous  ftp  from  csc.ti.com. 


2.5.7  Garnet.  Garnet  is  a  GUI  with  many  high-level  design  and  development 
features.  It  does  not  depend  on  CLOS,  but  does  depend  on  CLX.  Garnet  (version  2.0  and 
after)  is  public  dommn  and  has  no  licensing  restrictions.  It  runs  in  virtually  any  Common 
Lisp  environment,  including  Allegro,  Lucid,  CMU,  and  Harlequin  Common  Lisps.  (14) 

2.5.8  Lisp  View.  LispView  is  a  GUI  written  at  Sxm  that  does  not  use  CLX.  It 
converts  Xlib.h  directly  into  Lucid  Lisp  function  calls.  LispView  is  a  generic  Application 
Programmer’s  Interface  (API)  that  provides  Lisp  progrEunmers  with  a  powerful  set  of 
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tools  to  build  sophisticated  GUIs.  It  supports  output  functions  for  windows  as  well  as  a 
sophisticated  input  model  for  h2uidling  events.  LispView  provides  sets  of  generic  functions 
for  reading  and  writing  the  state  of  an  object.  LispView  can  also  translate  an  interface 
developed  with  the  OpenWindows*"^  Developers’  Guide  (Devguide)  Interface  Builder.  It 
is  available  for  anonymous  ftp  from  export.lcs.mit.edu.  (14) 

2.5.9  Winterp.  WINTERP  (Widget  INTERPreter)  was  developed  at  Hewlett- 
Packard  2ind  uses  the  Xtoolkit  and  Motif  widget  set.  It  is  a  free-standing  Lisp-based 
tool  for  setting  up  window  applications.  WINTERP  enables  rapid  prototyping  of  GUIs 
through  the  inter2w:tive  manipulation  of  user  interface  objects  and  their  attached  actions. 
WINTERP  supports  rapid  prototyping  of  GUI-based  applications  by  zJlowing  the  user  to 
intereictively  change  both  the  UI  appearance  and  application  functionality.  WINTERP  is 
available  via  anonymous  ftp  from  export.lcs.mit.edu.  (12) 

2.5.10  XIT.  X  User  Interface  Toolkit  (XIT)  is  an  object-oriented  user  interface 
development  environment  for  the  X  Window  System  based  on  Common  Lisp,  CLOS,  CLX, 
and  CLUE.  It  was  developed  at  the  University  of  Stuttgart.  XIT  contains  user  interface 
toolkits,  including  genersd  building  blocks  and  mechetnisms  for  building  arbitr2uy  user 
interf^u:e  elements.  It  also  has  a  set  of  predefined  common  elements  (widgets),  as  well  as 
high-level  intereictive  tools  for  constructing,  inspecting,  and  modifying  user  interfaces  by 
means  of  direct  manipulation.  XIT  is  currently  under  active  development,  but  is  avmlable 
by  anonymous  ftp  from  ftp.informatik.uni-stuttgart.de.  (14) 
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2.6  Conclusion 


Although  much  h2«  been  written  about  designing  human-computer  interfaces  emd 
many  guidelines  have  been  developed,  a  cookbook  recipe  for  building  a  GUI  does  not 
exist.  The  most  critical  GUI  design  steps  are  the  choice  of  metaphors  appropriate  to  the 
domain  of  interest  and  the  selection  of  icons  to  convey  the  metaphors.  Well-designed  icons 
make  an  interface  intuitive  jind  pleasemt  to  use.  Judicious  addition  of  color  to  an  interfau^e 
can  enable  the  application  specialist  to  easily  key  on  critical  relationships  and  to  maintain 
an  awareness  of  his  situation.  The  design  considerations  presented  in  this  chapter  were 
taken  to  heart  and  are  evident  in  several  aspects  of  the  design  of  AVSI II. 
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III.  System  Enhancements 


3.1  Introduction 

AVSI  w^ls  completely  adequate  as  a  proof-of-concept  visual  programming  tool.  How¬ 
ever,  as  Architect  has  evolved  into  a  more  sophisticated  application  composition  eind  gen¬ 
eration  system,  the  visual  aesthetics  of  the  interface  directly  impact  the  system’s  usability. 
As  stated  in  Chapter  11,  if  a  graphical  interface  is  not  easier  to  use  than  the  alterna¬ 
tive  (say,  a  command  line  interface),  the  graphical  interface  will  not  be  used.  Therefore, 
improvement  of  the  presentation  and  usability  of  AVSI  was  the  goal  of  this  research  effort. 

The  structure  of  an  Architect  application  is  based  on  the  Object  Connection  Update 
(OCU)  Model  developed  by  the  Software  Engineering  Institute  (SEI)  (15).  The  OCU  model 
consists  of  severed  software  elements  used  to  express  a  design  in  the  form  of  subsystems 
and  hardware  interfaces.  A  subsystem,  visualized  in  Figure  3.1,  consists  of  a  controller,  a 
set  of  objects,  an  import  eu'ea,  emd  an  export  area.  A  software  system,  or  application,  is 
described  as  a  set  of  subsystems  controlled  by  an  executive  function.  An  executive,  then, 
is  a  high  level  supervisory  subsystem  that  coordinates  the  behavior  and  information  flow 
between  subordinate  subsystems.  The  OCU  model  treats  subsystems  as  self-contadned, 
abstract  units;  however,  there  are  no  restrictions  against  a  subsystem  acting  as  an  object 
controlled  by  2inother  subsystem.  The  components  of  a  subsystem,  mentioned  above,  are: 

•  Controller:  The  controller  aggregates  a  set  of  objects  and  manages  the  connections 
between  them  and  the  flow  of  information  to  and  from  them,  based  on  the  function 
or  purpose  of  a  subsystem. 
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Objects  |J 

Figure  3.1  OCU  Subsystem  Diagram 

•  Import  area:  The  import  ajea  is  the  central  collection  point  for  the  inputs  needed 
by  the  objects  in  a  subsystem.  The  import  area  collects  data  from  other  subsystems 
in  an  application  and  makes  it  available  to  the  objects. 

•  Export  area:  The  export  eirea  is  the  central  distribution  point  for  the  outputs  of  a 
subsystem  that  is  needed  by  other  subsystems  in  an  application. 

•  Object:  An  object  models  the  behavior  of  real-world  components.  An  object  main¬ 
tains  a  state  and  has  an  associated  set  of  algorithms  responsible  for  transforming 
input  data  into  the  state  data. 

The  visualization  philosophy  used  in  the  development  of  AVSI II  was  to  emulate  and 
graphically  display  the  application  composition  process  in  a  manner  consistent  with  the 
OCU  concepts,  as  well  as  incorporating  the  domeiin-specific  graphical  representations. 


3.2  Operational  Concept 


The  application  specialist  must  proceed  through  several  steps  to  develop  a  complete 
application  and  simulate  its  execution  or  operation  through  AVSI.  First,  he  selects  the 
application  domain,  creates  the  application,  and  defines  a  controlling  subsystem.  Second, 
the  application  specialist  incorporates  lower  level  subsystem  and  primitive  objects  into  the 
application.  Next,  he  defines  the  order  in  which  each  primitive  object  in  the  application  is 
updated  (using  the  object’s  particular  update  algorithm).  Lastly,  the  application  specialist 
defines  how  the  primitive  objects  communicate  by  connecting  each  object’s  export  (or 
produced  signal)  to  the  appropriate  object’s  import  (or  consumed  signal).  Once  these 
steps  cire  taken,  the  application  spacizdist  has  fully  dclined  the  application’s  composition 
and  behavior.  Execution  of  the  application  can  then  be  simulated  to  compare  its  behavior 
to  the  behavior  expected  from  the  design. 

AVSI  alrezidy  provides  a  means  to  perform  each  step  outlined  above;  however,  the 
actual  process  and  appearance  of  the  interface  was  improved  in  several  significant  ways. 
The  following  subsections  describe  each  of  the  ezirlier  mentioned  steps  in  more  detail,  cover¬ 
ing  the  limitations  of  AVSI’s  original  design  and  outlining  the  improvements  incorporated 
into  AVSI  II.  The  presentation  of  information  is  roughly  in  the  order  it  was  accomplished. 
The  enhancement  to  AVSI  was  accomplished  as  a  stepwise  refinement,  with  one  area  of 
enhancement  being  completed  before  expzmding  into  another  area.  This  process,  although 
somewhat  given  to  duplicative  effort,  ensiured  a  fully  functional  interface  at  every  step  of 
the  development.  The  steps  taken  to  design  and  implement  the  improvements  are  dis- 
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cussed  in  more  detail  in  Chapter  IV.  For  more  information  on  the  original  design  and 
basic  fimctionality  of  AVSI,  see  Weide  (33). 

AVSI  II  uses  a  control  panel  window  as  the  central  interface  to  Architect.  The 
control  panel  consists  of  an  array  of  buttons  and  a  message  window.  The  buttons  are  used 
to  create  smd  edit  applications,  edit  subsystems,  define  an  application’s  import  and  export 
area  connections,  and  initiate  execution  of  the  application. 

3.2.1  Defining  the  Application.  The  application  specialist  creates  an  application- 
object  in  this  step  by  selecting  “Create  New  Application”  from  the  control  panel.  He 
is  then  prompted  for  the  application  domain,  the  application  name,  and  the  execution 
mode  of  the  application.  The  execution  mode  selection  is  a  new  feature  of  AVSI  II. 
It  was  required  to  support  the  Application  Executive  developed  by  Welgan  (34).  The 
application-object  has  no  functional  capability  and  serves  as  little  more  than  an  identifier 
for  the  application  being  composed.  Therefore,  once  the  application  has  been  created,  the 
application  specisdist  selects  “Edit  Application”  from  the  control  panel  in  order  to  create 
a  controlling  (or  supervisory)  subsystem  for  the  application.  Selecting  the  button  exposes 
the  edit-application-window,  which  cont2iins  a  single  icon  representing  the  newly  created 
application.  The  subsystem  is  created  by  clicking  the  mouse  button  on  the  surfjice  of 
the  edit-application-window  and  selecting  “Create  New  Subsystem”  for  the  pop-up  menu. 
Once  the  subsystem  is  created  and  neuned,  it  is  linked  to  the  application  by  clicking  the 
mouse  on  the  subsystem  icon  and  selecting  “Link  to  Source”  firom  the  pop-up  menu.  The 
link  is  then  created.  The  process  is  eflUcient  and  straight-forward.  Subsequently,  there  wsis 
very  little  room  for  improvement  in  the  basic  interface  method. 
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Due  to  Intbrvista’s  limited  choice  of  icons,  the  application  object  and  subsystem 
locked  the  same  in  the  edit-application-objects  window.  The  only  difference  in  the  objects 
vfos  the  icon  label  (Figure  3.2).  Bit-mapped  images  with  more  descriptive  size,  shape, 
and  design  were  developed  to  supplement  the  iNTERViSTA  icons.  The  new  bit-mapped 
icons  incorporate  the  principle  of  global  superiority  introduced  in  Section  2.2.1.  Figure 
3.3  depicts  the  full-size  and  half-size  icons  developed  for  the  application  and  subsystem 
objects.  The  distinctive  size  and  shape  of  the  icons  make  them  immediately  recognizable 
without  the  need  to  read  the  label. 

In  AVSI,  no  color  (other  than  black  and  white)  was  used.  An  additioncil  enhancement 
to  the  edit-application-window  was  to  change  the  background  color  of  the  window  to  light 
blue.  Section  2.4.1  outlined  the  power  of  using  color  as  a  visual  cue  to  the  user  of  a  system. 
In  this  case,  a  glance  at  the  screen  to  see  the  light  blue  is  enough  to  tell  an  application 
specialist  he  is  in  a  window  where  application  or  subsystem  building  is  done.  The  color 
blue  was  selected  because  it  is  often  associated  with  the  sensations  of  cool  or  peaceful.  The 
intent  of  using  blue  was  to  reduce  anxiety  or  relax  the  application  specialist  during  the 
creation  of  the  application. 

3.2.2  Building  the  Subsystems.  Once  the  application  has  been  created,  the  ap¬ 
plication  specialist  needs  to  create  the  lower  level  subsystem-objects  and  primitive-objects 
that  constitute  the  application.  Upon  selecting  “Edit  Subsystem”  from  the  control  panel, 
the  application  specialist  is  presented  with  a  window  that  represents  the  subsystem-object 
as  a  subsystem  diagram  from  the  Software  Engineering  Institute  (SEI)  Object-Connection- 
Update  (OCU)  model  (15:18).  AVSI  displayed  the  diagram  using  two  diamond  shaped 
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Figure  3.2  AVSI  Application  and  Subsystem  Icons 
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Figure  3.4  OCU  Model  Subsystem  Di^lg^am 


icons  and  two  box  shaped  icons.  Using  bit-mapped  icons,  AVSI  II  displays  the  diagram 
using  the  same  shapes  as  the  SEI.  Although  there  is  no  functional  difference  between  the 
representations,  AVSI  IPs  display  is  more  readily  recognizable  as  an  OCU  model.  Figure 
3.4  shows  both  representations  of  the  subsystem  diagram.  This  window  was  not  given  a 
colored  be«:kground.  The  intent  of  color  in  AVSI  II  was  to  draw  attention  to  significant 
windows  and  eiction  areas.  The  subsystem  window  is  em  intermediate  window  where  no 
design  activity  occurs. 

By  clicking  a  mouse  button  on  the  “Objects”  icon,  the  application  specialist  opens 
two  windows  where  he  creates  new  subsystem-objects  ^uld  primitive-objects  for  the  ap¬ 
plication.  The  leftmost  window,  called  the  edit-subsystem-window,  initially  contains  a 
single  subsystem-object  icon.  The  rightmost  window,  called  the  technology-base-window, 
contains  a  set  of  icons  representing  the  primitive  objects  that  are  valid  within  the  current 
application  domain.  The  application  specialist  can  add  new  subsystems  to  the  application 
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by  clicking  a  mouse  button  on  the  edit-subsystem-window  background  and  selecting  the 
appropriate  option  from  the  resulting  menu,  or  add  primitive-objects  by  clicking  a  mouse 
button  on  the  object  in  the  technology-base-window  and  clicking  the  mouse  again  on  the 
location  in  the  edit-subsystem-window  where  the  primitive  should  be  placed.  As  each  icon 
is  placed  in  the  edit-subsystem-window,  it  is  linked  to  an  appropriate  subsystem  by  cUcking 
the  mouse  on  the  icon,  selecting  “Link  to  Source”  from  the  menu,  and  clicking  the  mouse 
on  the  source  subsystem. 

A  functional  enhancement  was  made  in  AVSI II  that  edlows  the  application  specialist 
to  meike  multiple  links  at  one  time.  By  clicking  the  mouse  on  a  subsystem,  the  application 
specialist  can  select  “Link  Multiple  Targets”  from  a  menu  and  be  presented  with  a  Ust  of 
all  icons  in  the  window  that  are  not  currently  linked  to  a  subsystem.  He  can  then  select  all, 
some,  or  none  of  the  objects  and  the  interface  will  create  all  indicated  links  at  once.  As  an 
example,  to  connect  six  primitives  to  a  subsystem  under  AVSI,  the  application  specialist 
must  perform  18  distinct  mouse  actions.  Using  AVSI  II,  the  appUcation  specialist  c^m 
perform  the  same  task  with  only  four  mouse  actions.  The  multiple  link  capability  greatly 
enhances  the  interface’s  usability. 

The  visusd  enh2uicement8  to  this  portion  of  the  process  also  involved  icon  improve¬ 
ment  Eind  the  use  of  color.  The  improved  icon  used  for  subsystem-objects  was  discussed 
in  the  previous  section.  The  primitive-objects  in  Architect  and  AVSI  II  are,  for  the  most 
part,  unique  to  a  pzirticuleir  dom2un.  Therefore,  the  icons  used  to  represent  the  primitives 
should  be  unique  as  well.  Addition^llly,  the  icons  should  have  some  associated  meaning. 
The  metaphor  design  concepts  discussed  in  Section  2.2.2  have  direct  beeiring  on  the  icons 
developed  for  use  with  AVSI  II.  Whereas  AVSI  was  restricted  to  box,  diamond,  and  ellipse 
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shapes  to  iconically  represent  the  primitive-objects,  AVSI II  takes  advantage  of  metaphors 
inherent  in  an  application  domain  to  “show”  the  application  specialist  which  primitives  are 
available.  Figures  3.5  and  3.6  illustrate  the  icons  used  in  AVSI  and  AVSI  II,  respectively, 
for  the  primitives  in  the  logic-circuits  domain  of  Architect.  It  is  easy  to  understand  how 
the  AVSI  II  icon  set  shortens  the  application  specialist’s  titsk  of  locating  and  selecting 
a  specific  primitive-object  from  the  technology-bi«e-window.  Chapter  IV  addresses  the 
specific  design  considerations  that  went  into  developing  the  logic-circuits  set.  Appendix  B 
provides  a  detailed  process  for  creating  AVSI  II  icons  for  an  application  domain’s  primitive 
metaphors. 

Both  the  AVSI  and  AVSI  II  icon  sets  present  an  icon  as  a  shape  with  the  primitive 
object-class  nzune  as  a  label.  In  AVSI  the  label  is  necessary  for  the  application  specialist 
to  know  which  primitive  a  particular  icon  represents.  AVSI  II  retains  the  convention  of 
providing  the  object-class  name  as  the  label.  Although  a  simple  domain  like  the  logic- 
circuits  domain  (used  throughout  this  document  as  an  example)  m2dces  the  label  seem  like 
redimdzmt  information,  a  more  complex  domain  may  use  more  abstract  metaphors  as  icons. 
The  label  serves  to  associate  an  icon  with  a  primitive  object.  However,  when  a  primitive 
is  selected  from  the  technology-base-window  and  added  to  the  edit-subsystem-window, 
the  application  specialist  assigns  each  instantiation  of  the  primitive  a  name  unique  to  the 
application.  For  AVSI,  the  primitive  name  is  eidded  to  the  object-class  name.  Without 
retaining  the  object-class  nsune,  confusion  could  result  from  the  fact  that,  for  example,  the 
icons  for  a  mux-,  nand-,  and  nor-object  look  virtually  identical.  The  bit-mapped  im2iges 
used  as  icons  in  AVSI  II  allow  enough  specificity  and  variability  in  the  icons  that  the 
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object-class  name  is  no  longer  required  and  the  name  of  the  particvilar  primitive  instance 
is  sufficient  identification. 

Color  was  used  to  provide  the  application  specialist  with  basic  situational  awareness, 
in  the  same  manner  as  described  in  the  previous  section.  The  edit-subsystem-window 
has  the  same  light  blue  background  as  the  edit-application-window  to  indicate  that  the 
windows  have  the  same  basic  functionality.  The  technology-base-window  was  given  a  green 
background.  The  technology-base-window  is  the  only  green  window  in  AVSI  II,  thereby 
making  it  immediately  recognizable.  Green  is  also  a  color  culturally  associated  with  safe 
or  go.  This  is  appropriate  for  the  technology-base-window  since  there  is  no  design  activity 
in  the  window,  it  is  simply  a  source  of  the  primitives. 

Color  was  not  used  in  the  design  of  the  icons  themselves.  The  primary  reason  was 
a  desire  to  avoid  the  ‘‘firuit  salad”  effect  mentioned  in  Section  2.4.2.  Another  reason  was 
a  fall-out  of  designing  for  monochrome  first  and  adding  color  to  a  display  later  (Section 
2.4).  Once  the  icons  were  designed  and  incorporated  into  a  monochrome  AVSI  II,  there 
was  no  compelling  reason  to  rebuild  the  icons  in  color.  Additionally,  Table  2.1  indicated 
that  black  was  the  preferred  color  for  text  and  lines  on  colored  backgrounds. 

3.2.3  Specifying  the  Update  Algorithm.  An  update  algorithm  is  built  for  each 
abstract  level  of  an  application.  For  any  subsystem,  the  update  algorithm  is  defined  for 
those  objects  (subsystem  and  primitive)  that  aure  controlled  by,  or  linked  to,  the  subsystem. 
At  the  application  level,  the  process  for  creating  an  update  is  entered  through  a  menu 
selection  off  the  AVSI  control  panel.  At  a  subsystem  level,  it  is  entered  by  clicking  the 
mouse  on  the  “Controller”  icon  in  the  current  subsystem  dii^am  window.  With  AVSI, 


the  application  specialist  was  presented  two  edlt-update-algorithm  windows:  one  giving  a 
graphical  (iconic)  view  of  the  update  algorithm,  and  one  giving  the  textual  view.  To  add 
a  primitive’s  update  function  to  the  algorithm,  the  application  speciedist  had  to  click  on 
a  “nub”  in  the  graphical  window,  select  the  t)rpe  of  update  to  be  added  (typicedly  a  csdl 
to  a  primitive’s  update  function),  and  enter  the  naune  of  the  operand  of  the  update  call. 
Each  operauid  is  generically  represented  by  a  simple  box  icon  and  the  operand  name.  It 
is  important  to  note  that  the  name  of  the  operand  in  the  update  call  must  exactly  match 
the  instantiated  name  of  the  object  in  the  application.  Unfortunately,  the  edit-*-window 
that  shows  the  names  of  the  subsystem  and  primitive  objects  that  apply  to  the  update 
algorithm  is  not  normally  visible  during  this  process  (Note:  edit-*-window  is  used  in  this 
chapter  to  indicate  that  the  statement  is  equally  applicable  for  the  edit-application-window 
and  the  edit-subsystem- window).  For  a  long  update  sequence,  the  update  becomes  tedious 
and  presents  numerous  opportunities  for  the  application  specialist  to  incorrectly  enter  an 
opercind  neime. 

The  procedure  for  building  the  update  algorithm  under  AVSI  11  needed  to  be  less 
tedious  and  less  susceptible  to  mistakes.  The  key  to  simplifying  the  process  was  creating 
a  new  window,  called  the  controllee-window,  that  displays  all  subsystem-  and  primitive- 
objects  controlled  by,  or  linked  to,  the  current  subsystem.  The  controllee-window  displays 
a  copy  of  the  icons  created  in  the  edit-*-window  and  two  additioneil  icons  that  represent 
if-then  and  do- while  constructs.  To  build  the  update  algorithm,  the  application  specialist 
clicks  the  mouse  on  an  icon  in  the  controllee-window.  The  mouse  cursor  changes  to  a 
“bullseye”  shape,  and  the  application  specialist  can  click  on  a  “nub”  in  the  edit-update- 
eilgorithm  window.  AVSI  II  automaticEiUy  adds  the  icon  to  the  graphical  update  window. 
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and  the  represented  object  to  the  textual  update  window.  To  create  a  six  object  update 
cdgorithm,  AVSI  required  an  application  specialist  to  perform  42  distinct  actions  as  well  as 
remember  the  precise  name  of  all  six  objects.  Using  AVSI  II,  the  application  specialist  only 
performs  two  mouse  ^lctions  per  object,  or  a  total  of  12  actions.  There  is  almost  no  source 
of  error  since  the  application  specialist  does  not  need  to  enter  any  operamds  or  remember 
euiy  names,  thus  reducing  the  time  required  to  build  an  update. 

One  additional  time  saving  featime  was  implemented  for  this  process.  During  the 
construction  of  the  update  algorithm,  three  different  windows  are  continuously  exposed. 
The  “Deaictivate”  menu  choice  was  changed  for  the  graphical  update  window  to  deactivate 
2dl  three  windows  with  a  single  selection,  thus  reducing  the  application  specialist’s  workload 
from  six  actions  to  two. 

As  with  the  other  AVSI  II  windows  where  graphical  information  is  being  displayed, 
the  controllee-window  2ind  the  graphical  edit-update-algorithm  window  were  given  a  dis- 
ti’^ctively  colored  backgroimd.  In  this  instance,  yellow  was  chosen  based  on  the  gmdelines 
discussed  in  Section  2.4.1.  Yellow,  a  color  traditionally  associated  with  caution  in  Ameri¬ 
can  society,  was  chosen  for  the  update  windows  to  convey  that  the  actions  taken  to  build 
an  update  algorithm  are  less  flexible,  and  the  order  of  the  objects  in  the  update  is  more 
critical,  than  the  actions  and  order  involved  in  linking  primitives  and  subsystems  in  the 
edit-*-window.  CJolor  was  not  added  to  the  textual  update  window,  or  any  other  text 
based  window  in  AVSI  II  for  the  same  reasons  discussed  in  Section  3.2.2.  The  text  based 
windows  are  primarily  information  only  and  no  actions  are  required  in  them. 


3-13 


3.2.4  Connecting  the  Imports  and  Exports.  The  import  objects  (targets)  and 
export  objects  (sources)  are  connected  at  two  levels.  Connections  can  be  mside  within  a 
subsystem  or  between  subsystems.  Using  AVSI,  the  application  specialist  made  the  import- 
export  connections  by  first  clicking  on  the  “Build  Import  and  Export  Areas”  button  on 
the  control  panel.  A  new  window,  the  import-export- window,  opened  and  displayed  one 
or  more  three  icon  groups  that  represented  ail  subsystems  in  the  application  and  the 
subsystems’  import  and  export  areas  (see  Figure  3.7).  The  same  icon  group  was  used  for 
representing  primitive  objects.  The  OCU  model  permits  subsystems  to  be  made  objects 
(or  subordinate  subsystems)  of  another  subsystem.  With  AVSI,  if  a  subsystem  controlled 
other  subsystems,  the  lower  level  subsystems’  connections  were  made  by  clicking  on  the 
subsystem  icon’s  centred  box  and  selecting  “Make  Internal  Connections”  from  the  resulting 
menu.  This  action  opened  an  import-export-window  containing  the  lower  level  subsystem’s 
controUees. 

To  make  the  connections,  the  application  specialist  selected  an  import  or  export  eirea 
by  clicking  on  it.  A  text  window  listing  the  import  or  export  objects  in  that  particular 
import  or  export  area  appeared.  The  application  specialist  then  selected  em  import  or 
export  object  with  the  mouse,  and  a  set  of  dashed  links  appeared  that  indicated  the  aureas 
that  contedned  possible  sources  or  targets  with  which  to  connect.  He  then  clicked  on  a 
different  export  or  import  area  icon  (one  indicated  by  a  link),  and  selected  an  export  or 
import  object  from  the  text  window  that  opened.  This  process  was  repeated  imtil  all 
imports  had  been  connected  to  at  least  one  import  and  all  imports  were  connected  to  one 
export. 
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Figure  3.7  AVSI  Import/Export  Icon 


Figure  3.8  AVSI  II  Import/Export  Subsystem  Icon 

Because  of  AVSI’s  abstract  representation  of  the  import  and  export  areas,  the  ap¬ 
plication  specialist  had  no  direct  feedback  about  which  specific  import  and  export  objects 
were  connected.  The  application  specialist  only  knew  that  something  in  one  area  was 
connected  to  something  in  emother.  The  abstraction  makes  sense  for  subsystem  objects 
that  are  abstract  by  nature,  but  it  is  a  hindrance  to  understanding  the  connections  be¬ 
tween  primitives.  Additionedly,  the  primitive-objects  were  not  presented  to  the  application 
specialist.  Rather,  listings  of  the  primitive’s  imports  and  exports  were  displayed.  The 
import-export-window  provided  no  visual  feedback  about  which  icon  groups  represented  a 
specific  primitive  2ind  which  represented  subsystems.  Improvement  to  the  visual  presenta¬ 
tion  in  the  import-export-window  included  redesign  of  the  subsystem  icon  group  to  look 
more  like  the  OCU  subsystem  diagram  discussed  in  Section  3.2.2  (see  Figure  3.8).  Further 
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improvement  was  reidlzed  by  displaying  the  specific  primitive’s  metaphor  in  place  of  the 
icon  group. 

One  visuzd  representation  of  connections  between  subsystem  import  and  export  areas 
(like  in  the  OCU  model)  is  an  abstract  link  between  data  aureas.  AVSI  awrcurately  portrayed 
the  abstraction,  however,  primitive-objects,  like  the  OCU  model’s  objects,  represent  real- 
world  entities  (15:19).  AVSI  II  re-implements  the  subsystem’s  internal  connection  process 
(i.e.,  that  of  connecting  the  primitive’s  imports  aind  exports)  by  displaying  the  primitive’s 
bit-mapped  icon  and  allowing  the  application  specialist  to  link  specific  import  objects  to 
specific  export  objects.  AVSI  did  not  display  sub-subsystems  and  primitives  of  a  subsystem 
in  the  same  connection  window.  Instead,  all  subsystems  in  an  application  were  displayed  in 
one  import-export-window,  and  the  primitives  controlled  by  a  subsystem  were  connected 
by  selecting  “make  internal  connections.”  This  brought  up  another  import-export-window 
containing  only  the  subsystem’s  primitives.  AVSI  II  displays  all  objects  controlled  by  a 
subsystem  in  the  same  window. 

To  make  import-export  connections  in  AVSI  II,  the  application  specialist  begins  by 
moving  the  icons  from  their  default  display  locations  to  some  “signific^lnt”  position  in  the 
window.  The  default  display  locations  are  determined  through  a  simple  automatic  layout 
algorithm.  AVSI  II  does  not  have  sufiicient  “knowledge”  of  the  application’s  design  to 
accurately  place  the  icons;  therefore,  the  application  specialist  has  the  option  to  move  the 
icons.  Section  2.3  discussed  how  the  relative  location  of  objects  in  a  display  can  impact  a 
user’s  ability  to  understand  and  use  an  interfcice. 
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Eaxrh  primitive’s  icon  consists  of  the  bit-mapped  image  and  label  that  identifies  the 
primitive  object,  and  a  set  of  mouse  sensitive  ‘fields’  that  correspond  to  the  imports  and 
exports  defined  for  the  primitive.  For  excunple,  a  2-input  And-gate  primitive  would  have 
two  import  fields  and  one  export  field.  Figure  3.9  shows  the  And-gate  primitive  with  the 
import  and  export  fields  illustrated  as  grey  outlines.  Imports  are  connected  to  exports 
by  selecting  an  export  field  with  the  mouse  and  then  selecting  the  destination  import 
field.  The  link  is  automatic  and  visible.  The  converse  (i.e.,  connecting  an  export  to  an 
import)  also  holds.  Unlinked  import  and  export  fields  are  displayed  in  reverse  video  to 
indicate  to  the  application  specialist  that  connections  still  need  to  be  made.  Once  the 
connection  is  made,  the  connected  fields  disappear  (un-highlight).  The  fields  can  easily 
be  found  from  the  termination  of  the  links  representing  the  connection.  The  overall  effect 
of  AVSI  II’s  internal  subsystem  connection  process  is  one  of  “hooking  up”  the  primitives. 
Because  the  application  specialist  is  typically  not  a  programmer,  it  is  important  to  reduce 
the  abstraction  of  the  import-export  display  to  make  the  connection  process  more  natural 
and  intuitive. 

Connecting  a  primitive-object  to  an  object  within  another  subsystem  is  a  blend  of 
the  subsystem  and  primitive  connection  processes.  Clicking  on  an  subsystem’s  import  or 
export  area  icon  exposes  a  text  window  displaying  the  imports  or  exports  of  the  subsystem. 
Clicking  on  an  icon’s  field  and  then  on  a  text  window  entry  creates  em  import-export  link. 
Alternately  selecting  a  text  window  entry  and  then  clicking  on  ein  icon’s  field  also  creates 
the  import-export  link.  The  visual  feedback  is  in  the  form  of  an  updated  text  entry  showing 
the  connection  and  the  field  changing  to  an  empty  box  that  means  “there  is  a  connection 
made,  but  not  to  an  object  visible  in  the  same  window  as  the  icon.” 
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Figure  3.9  2-Input  And-Gate  in  AVSI II 

The  ability  to  close  multiple  windows  simultaneously  was  added  to  the  import-export- 
window  menu.  The  application  specialist  has  a  choice  of  closing  only  the  import-export- 
window  by  selecting  “Deactivate”  from  the  window’s  title-bar  menu,  or  closing  the  import- 
export-window  and  all  exposed  text  windows  simultaneously  by  selecting  “Deactivate”  from 
the  window’s  surface  menu. 

Red  was  chosen  for  the  background  color  of  the  import-export-windows.  Culturally, 
red  represents  danger,  heat,  or  warning.  For  AVSI  11,  red  is  intended  to  convey  to  the 
application  specialist  that  the  import-export  connection  process  is  the  most  complex  and 
error  fraught  part  of  composing  an  application.  Red  is  meant  to  instill  a  sense  of  caution 
jind  deliberation  in  the  application  specialist  diuing  the  connection  activity. 

3.2.5  Executing  the  Application.  Once  the  application  has  been  built  and  seman¬ 
tically  checked,  the  application  specialist  will  likely  execute  it.  This  is  accomplished  by 
clicking  on  the  “Execute  Application”  button  on  the  control  panel.  If  the  application  heis 
a  sequential  execution  mode,  the  execution  simply  proceeds  and  the  results  are  displayed 
in  the  EMACS  window.  If  the  application  has  an  event-driven  execution  mode,  a  text 
window  displaying  the  current  contents  of  the  event  queue  is  exposed.  The  window,  shown 
in  Figure  3.10,  also  contains  fomr  control  selections  that  allow  the  application  specialist 
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Event  Hane  Event  Ovner  Priority  Coaaent 

A  Start  Event 
A  Tranenit  Event 
An  Activate  Event 
A  Receive  Event 
A  Done  Event 
A  Stop  Event 


ADO  an  Event  to  the  Queue 
MOOIPy  an  Event  on  the  Queue 
DELETE  an  Event  froa  the  Queue 

BEGIN  EXECUTION  •  editing  coaplete 

Figure  3.10  Event  Queue 

to  add  events  to  the  queue  through  a  set  of  input  menus,  modify  events  on  the  queue,  or 
delete  events  from  the  queue.  When  all  changes  have  been  made,  “Begin  Execution”  can 
be  selected  from  the  window.  Execution  then  begins  and  the  results  lure  displayed  in  the 
EMACS  window. 

3.3  Testing 

The  purpose  of  this  research  effort  was  to  enhance  the  aesthetic  appearance  and 
usability  of  the  graphical  interface  to  Architect  without  compromising  or  degrading  AVSI’s 
basic  functionality.  The  formal  testing  of  AVSI II  took  on  two  distinct  aspects.  The  first 
aspect  was  a  strictly  objective  test  of  AVSI  II’s  functionality.  All  of  this  testing  of  AVSI 
II  was  conducted  with  applications  developed  from  the  digital  logic-circuits  domain,  since 
that  was  the  only  fully  validated  domain  available.  The  second  aspect  was  an  objective  amd 
subjective  evaluation  of  the  ability  of  am  application  speciidist  to  use  and  imderstand  the 
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interface.  AVSI II  also  received  extensive  informal  testing.  Two  research  efforts,  concurrent 
with  AVSI  II  development,  were  developing  additional  application  domains  for  Architect. 
The  domzdns  were  implemented  through  AVSI  II,  and  the  researchers  provided  valuable 
feedback  and  recommendations  regarding  AVSI  II’s  appearance  and  usability.  The  details 
of  the  formed  cind  informal  testing  and  the  test  results  are  discussed  in  Chapter  V. 

3.S.1  Functionality  Testing.  This  phase  of  the  testing  proved  two  points:  AVSI 
II  is  fully  backward  compatible  with  all  applications  built  and  saved  using  either  the 
Architect  command-line  interface  or  AVSI,  and  AVSI  II  did  not  negatively  impact  the 
functionality  of  Architect.  First,  four  applications  built  prior  to  AVSI  II  development  were 
parsed  into  AVSI  II.  They  were  each  viewed  in  the  edit-application-window,  the  update- 
algorithm-window,  and  the  import-export-window  to  verify  that  the  appropriate  visual 
information  was  created  to  represent  each  application.  The  applications  were  executed 
md  the  behavior  weis  verified  against  predicted  behavior  derived  from  a  mEinueil  analysis 
of  the  circuit’s  design.  Eawjh  application  was  saved  back  to  system  files  and  the  new  files 
were  compared  to  the  files  of  the  originally  saved  applications  to  verify  the  integrity  of  the 
information.  Secondly,  four  applications  of  varying  complexity  were  built,  executed,  and 
saved.  The  execution  results  of  each  were  compared  to  predicted  execution  results  to  verify 
proper  behavior.  Each  saved  application  was  parsed  back  into  AVSI  II  and  viewed  in  the 
edit-application-window,  the  update-algorithm-window,  md  the  import-export-window  to 
verify  the  information  weis  properly  re-created.  Next,  the  applications  were  then  executed 
to  verify  that  proper  behavior  was  preserved. 
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3.3.2  Usability  Testing.  Objective  evaluation  of  AVSI  II  usability  required  de¬ 
velopment  of  metrics  or  figures  of  merit.  Several  figures  of  merit  were  considered.  The 
time  required  to  build  an  application  and  a  measure  of  the  errors  made  during  applica¬ 
tion  composition  were  considered  and  rejected  as  metrics.  Time  is  highly  dependent  on 
environmented  considerations  like  distractions  and  noise.  Error  rate,  although  normally  a 
useful  metric,  was  considered  less  importemt  them  the  capability  to  or  ease  of  recovering 
from  the  error.  Additionally,  the  current  users  of  AVSI  II  are  highly  experienced  with 
the  system  and  are  not  prone  to  errors.  For  these  reasons,  the  time  metric  was  not  used 
and  the  error  metric  was  monitored  as  part  of  the  subjective  testing  discussed  below.  One 
useful  figure  of  merit  was  developed.  The  measure  counted  the  nmnber  of  distinct  user 
actions  required  to  build  an  application.  A  user  action  is  a  specific  activity  such  as  clicking 
a  mouse  button  on  a  part  of  the  window  or  typing  in  a  name  from  the  keyboard.  This 
measure  positively  refiected  the  reduction  in  user  workload  with  AVSI  II.  To  some  extent, 
it  also  refiected  the  time  required  to  compose  the  application.  Data  was  collected  for  three 
different  applications  of  varying  complexity,  each  of  which  was  built  in  AVSI  and  AVSI  II. 

This  phase  of  the  testing  att  r  pted  to  measure  how  “good”  AVSI  II  is.  Much  of 
the  information  collected  here  was  derived  subjectively  by  feedback  from  other  members 
of  the  KBSE  reseeurch  group  who  were  2w:tively  using  AVSI  11.  Meiny  comments  on  the 
interface’s  usability  were  collected  informcilly  as  a  consequence  of  the  research  group’s  close 
working  proximity.  Other  information  was  collected  more  formally  through  a  survey  sheet 
that  delineated  the  chemges  from  AVSI  to  AVSI  II  and  provided  room  for  an  eveduation 
of  the  form  “significant  improvement,”  “some  improvement,”  “no  improvement,”  “some 
degradation,”  or  “significeint  degreidation”  of  the  change.  Additionzd  space  on  the  form  was 


3-21 


provided  for  the  user  to  make  einy  appropriate  comments.  The  feedback  was  consistently 
positive,  and  is  discussed  in  more  detail  in  Section  5.3.3. 

3.3.S  Informal  Testing.  Two  other  KBSE  researchers  made  extensive  use  of  AVSI 
II  during  its  design  and  development.  Warner  implemented  the  Digital  Signal  Processing 
(DSP)  domain  in  Architect  (32).  His  goal  was  to  verify  that  a  more  substantial  and 
complex  dommn  them  logic-circuits  could  be  implemented  in  Architect.  Waggoner  actually 
implemented  two  domains:  a  time  driven  extension  of  the  logic-circuits  domain  and  a 
moving  vehicle  (a  cruise  missile)  domain  (31).  His  goal  was  to  model  and  integrate  time- 
dependent  behavior  in  Architect. 

Once  their  theoretical  research  and  domain  modelling  was  completed,  each  researcher 
integrated  the  domains  into  Architect  and  AVSI  II.  Since  their  efforts  paralleled  the  devel¬ 
opment  of  AVSI  II,  they  had  first-hand  experience  with  the  capabilities  and  limitations  of 
AVSI  cmd  AVSI  II.  Msmy  comments  and  recommendations  from  their  integration  efforts 
contributed  to  the  successful  testing  of  AVSI  II,  and  those  comments  are  summarized  in 
Section  5.3.3. 

3.4  Conclusion 

AVSI,  the  Architect  Visual  System  Interface  created  by  Weide  (33),  was  a  funda¬ 
mental  keystone  of  Architect’s  usefulness.  Whereas  Weide’s  research  and  implementation 
concentrated  on  functionality,  this  thesis  effort  concentrated  on  the  appearance  and  us¬ 
ability  of  the  interface.  AVSI  II  allows  the  application  specialist  to  perform  the  task  of 
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modeling  and  executing  an  application  with  less  effort,  in  fewer  steps,  and  in  a  more  logical 
manner  than  he  could  with  AVSI. 

The  next  chapter  provides  information  relevant  to  the  design  decisions  and  tradeoffs 
experienced  in  developing  AVSI  II,  as  well  as  the  rationale  behind  those  decisions.  Ap¬ 
pendix  B  provides  a  description  of  the  details  of  how  a  domain  modeler  can  construct  an 
application  dommn’s  icon  metaphors  for  use  in  AVSI  II.  Appendix  A  provides  a  sample 
session  of  creating  an  application  with  AVSI  II. 


IV.  Design  and  Implementation  of  AVSI II 


4.1  Introduction 

A  basic  familiarity  with  INTBRVISTA  is  all  that  is  required  to  realize  that  its  graphical 
power  was  inadequate  for  the  development  of  AVSI  II.  As  mentioned  in  Section  2.5,  INTBR- 
VISTA’s  native  window  system  is  Common  Windows.  The  purpose  of  Common  Windows 
is  to  provide  an  interface  from  Lisp  to  the  general  window  ayatem  located  on  the  computer 
system.  The  version  of  Common  Windows  currently  available  uses  the  X  window  system 
and  Common  Lisp  X  Interface  (CLX)  (10:1-3).  CLX,  the  standard  X  interface  used  by 
Common  Lisp  programmers,  is  a  set  of  data  types,  functions,  and  macros  that  enable  a 
Lisp  user  to  interzurt  with  X  (27:1-3).  Conunon  Windows  (CW)  and  CLX  (CW’s  imderly- 
ing  system)  provide  a  wide  spectrum  of  graphical  capability.  Careful  review  of  Common 
Windows’  capabilities  indicated  it  would  provide  more  than  enough  graphical  augmenta¬ 
tion  to  Intervista  to  fulfill  the  goals  of  this  thesis.  Additionally,  since  direct  calls  to  CW 
from  within  iNTBRViSTA  are  possible  without  translation,  the  integration  of  CW  calls  into 
AVSI  II  was  straightforward.  The  relationship  between  the  layers  of  software  separating 
the  application  specialist  from  the  hardware  implementing  AVSI  II  is  depicted  in  Figme 
4.1. 

This  chapter  discusses  the  AVSI  II  design  and  implementation,  highlighting  Com¬ 
mon  Windows’  role  in  the  graphical  enhancement  and  the  reason  behind  the  usability 
enhancements. 
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Figvire  4.1  Software  Layers  Beneath  AVSI 


4.2  Design  and  Implementation  Approach 

AVSI  II  was  developed  using  incremental  development  eind  rapid  prototyping.  Many 
of  the  basic  concepts  and  procedures  used  to  improve  AVSI  II  were  developed  in  design 
environments  sepeu-ate  from  Architect  and  AVSI.  The  first  step  involved  creating  an  INTER- 
VISTA  window  for  design  experimentation.  Within  the  window  various  mouse  handler,  icon 
and  link  creation  and  m2mipulation,  and  window  sizing  options  were  investigated.  Then, 
another  experimentation  window  was  developed  in  Common  Windows.  In  that  window  the 
functions  to  manipulate  window  shape  eind  size,  window  foreground  and  backgroimd  col¬ 
ors,  bitmap  creation,  bitmap  foreground  and  background  colors,  text  creation,  creation  of 
mouse  sensitive  areas,  and  primitive  drawing  commands  were  investigated.  The  knowledge 
from  the  Common  Windows  experiments  was  then  applied  to  the  iNTERVISTA  environment 
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where  the  synteix  for  making  Common  Windows  function  calls  within  InTERVISTA  func¬ 
tions  was  developed.  This  phase  of  the  experimentation  developed  the  knowledge  required 
to  display  a  bitmap  from  Intervista;  tie  the  bitmap  to  an  INTERVISTA  icon;  create,  move, 
and  delete  the  icon-bitmap  pair;  zmd  display  colors. 

Using  the  experimental  windows  to  develop  a  design  knowledge  base  made  integrating 
the  bitmap  and  color  features  into  AVSI  II  a  significantly  easier  task.  Still,  in  order 
to  maintain  a  fully  functional  interface  during  sdl  stages  of  the  research,  an  incrementad 
development  approach  was  adopted.  The  order  of  discussion  in  Chapter  III  is  the  order  in 
which  the  interface  was  enhanced.  Bitmaps  were  integrated  first,  then  the  update  algorithm 
process  was  modified,  and  then  the  import-export  connection  process  was  redesigned. 

4.3  Domain  Specific  Icons 

The  topic  of  domeun-specific  graphics  was  at  the  heart  of  enhancing  AVSI.  Inter¬ 
vista  is  currently  unable  to  provide  icons  other  than  box,  ellipse,  and  diamond.  Text  icons 
are  not  considered  real  icons  for  the  purpose  of  this  discussion.  Although  the  line  thickness 
and  icon  height-to-width  ratio  cem  be  controlled,  the  basic  limitations  still  exist.  Common 
Windows  is  capable  of  reading  and  displaying  bitmap  files  in  either  XI 1  bitmap  format  or 
Interlisp-d  format.  The  bitmaps  can  be  viewed  in  an  INTERVISTA  window  in  conjunction 
with,  or  insteeid  of,  the  INTERVISTA  icon.  A  brief  explanation  of  the  icon  formats  follows: 

1.  The  Interlisp-d  format  is  actually  a  Lisp  list  that  is  converted  into  a  bitmap  stream  by 
the  CW  expr-to-bitmap  comm2ind.  The  most  convenient  way  to  build  an  Interlisp-d 


4-3 


bitmap  is  to  use  the  CW  drawing  functions  to  draw  the  bitmap  into  a  bitmap-stream 
and  then  save  it  to  a  bitmap  file  with  save-bitmap. 

2.  The  Xll  bitmap  format  is  significantly  easier  for  the  domain  modeller  to  manipulate. 
XI 1  bitmap  is  the  format  for  virtually  all  icons  displayed  on  the  screen  of  any  system 
running  the  X  windows  system.  Constructing  the  bitmap  is  easily  accomplished  using 
a  peunt  or  draw  package  that  can  save  in  Xll  format,  or  using  the  OpenWindows^" 
utility  Icon  Editor. 

Since  domain  modelers  should  not  be  required  to  learn  low-level  drawing  functions  in 
CW,  the  Xll  bitmap  format  was  chosen.  The  bitmaps  used  in  AVSI II  were  all  drawn  with 
Icon  Editor,  except  for  the  subsystem  bitmap  used  in  the  import-export-window.  That 
bitmap  was  built  in  IslandPaint^",  a  graphics  package  capable  of  reading  and  writing 
Xll  format  files,  and  exported  in  Xll  format.  The  following  subsections  discuss  how  the 
domain-specific  icons  for  the  AVSI  II  validation  dommn  (i.e.,  the  logic-circuits  domain) 
were  developed  and  detail  the  steps  taken  to  integrate  and  display  domain-specific  icons 
in  AVSI  II. 

4-3.1  Metaphor  Development.  Architect  is  used  to  instantiate  and  manipulate 
three  classes  of  objects:  Application-objects,  Subsystem-objects,  and  Primitive-objects. 
Application-objects,  subsystem-objects,  Eind  primitive-objects  are  defined  in  Architect’s 
grcunmar  and  domain  model  [see  (11)  for  a  discussion  of  Architect’s  architecture].  A  gram¬ 
mar  defines  the  leinguage  used  to  characterize  the  objects  in  a  domain,  while  a  domain 
model  defines  the  relationships  emd  behaviors  of  the  objects  in  a  domain.  While  primitive- 
objects  are  gener2dly  defined  in  the  Architect  grammar  and  domain  models,  the  relation- 


ships  and  behaviors  of  the  primitives  that  are  unique  to  a  specific  application  domain  are 
defined  in  a  domain-specific  grammar  and  domain  model. 

Because  application-objects  and  subsystem-objects  are  structurally  and  functionally 
identical  in  the  Architect  environment  regardless  of  the  application  being  composed,  the 
application-  and  subsystem-objects  were  e2w:h  given  a  single  metaphor  (icon).  However, 
the  primitive-objects  in  a  domain,  although  structursdly  similar,  vary  in  fimctionality  both 
between  and  within  specific  domains.  The  goal  of  a  metaphor  (or  icon)  is  to  reflect  the 
behavior  or  function  of  the  primitive-object,  so  individual  metaphors  for  each  primitive 
must  be  developed. 

An  application-object  in  Architect  is  the  top-level,  abstract  entity  that  defines  an 
application  and  its  function.  The  metaphor  for  the  application-object  must  convey  a  sense 
of  regulation  or  supervision  of  its  subcomponents.  Figure  3.3  showed  the  icons  developed 
to  represent  the  application-object.  Although  the  metaphor  may  not  be  readily  apparent, 
the  metaphor  for  an  Architect  application-object  is  an  architect  at  a  drafting  table.  The 
architect  is  the  individuzd  in  charge  of  the  design  of  a  project;  and  he  must  be  aware  of, 
and  in  control  of  all  aspects  of  the  project’s  (or  application’s)  design.  The  half-size  icon 
(see  Section  4.3.4  below)  represents  the  top  of  the  Eirchitect’s  drafting  table  where  rolled-up 
plans  or  design  tools  would  be  seen. 

The  subsystem-object  presented  a  significant  ch2dlenge  in  metaphor  design.  Although 
the  structure  and  functionality  of  a  subsystem  is  a  constant  in  Architect,  subsystem  mean¬ 
ing  and  relevzmce  can  be  quite  diverse  between  domains.  The  subsystem  icon  has  one 
proverbial  foot  in  the  domedn-specific  2urena  emd  the  other  in  the  Architect  general  2irena. 
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The  final  metaphor  design  is  reflected  in  Figure  3.3.  The  icon  looks  like  the  outer  edge 
of  a  partially  completed  puzzle.  The  metaphor  is  intended  to  convey  the  sense  that  a 
subsystem  is  a  collection  of  parts  -  specifically,  the  controlled  objects,  or  primitives,  that 
comprise  the  subsystem.  The  fact  that  the  puzzle  is  parti2dly  complete  is  significant  in 
that  an  Architect  subsystem  can  be  a  generic  object,  a  saved  but  incomplete  subsystem,  a 
complete  subsystem,  or  a  subsystem  still  being  defined. 

Applying  the  metaphor  design  guidelines  outlined  in  Chapter  II  was  a  straight¬ 
forward  task  for  the  logic-circuits  primitive-objects  in  the  AVSI  II  validation  domain. 
The  following  twelve  primitive-objects  are  defined  for  the  domain:  ^md-gate,  nimd-gate, 
or-gate,  nor-gate,  not-gate,  switch,  led,  multiplexer,  counter,  decoder,  j-k  flip-flop,  and  half 
adder.  Each  primitive  is  well  defined  amd  has  a  common  visualization  in  the  field  of  digital 
logic.  The  specific  metaphor  used  for  each  primitive  was  extracted  from  the  visual  repre¬ 
sentations  used  in  Digital  Logic  and  Computer  Design  by  Mano  (17).  Figure  3.6  shows  the 
bitmaps  drawn  for  the  logic-circuits  primitive-object  metaphors. 

The  final  step  in  metaphor  design,  according  to  Erickson  (9:68-72),  was  to  evaluate 
the  effectiveness  of  the  metaphors.  Feedback  from  KBSE  group  members  using  AVSI  II 
indicated  a  dissatisfaction  with  the  switch  icon.  The  origined  choice  of  a  switch  metaphor, 
although  easily  identified  as  a  switch,  implied  an  in-line  switch  requiring  an  input  and  an 
output.  In  fact,  the  switch  implemented  in  the  circuits  domain  only  has  an  output.  The 
inaccurate  metaphor  caused  confusion  concerning  the  actual  functionality  of  the  switch. 
Therefore,  the  metapho”  was  redesigned  to  reflect  the  switch’s  true  functionality.  The  final 
design  reflects  a  single  output  toggle  switch.  The  two  designs  are  shown  in  Figure  4.2. 
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Figure  4.2  Switch  Icons 

Appendix  B  explains  in  detail  the  process  a  domain  engineer  should  follow  to  develop 
a  set  of  icons  for  use  in  AVSI  li.  The  appendix  discusses  the  Icon  Editor  utility,  the  size 
and  format  of  the  bitmaps  to  be  created,  the  file  naming  convention  used,  amd  how  to 
include  the  bitmaps  in  the  domain  model. 

4.S.2  Icon  Display.  Once  the  appropriate  metaphors  were  developed  and  the 
bitmap  files  were  built  using  Icon  Editor,  the  bitmaps  had  to  be  displayed  in  an  Intervista 
window.  The  icons  displayed  and  manipulated  in  INTERVISTA  are  actually  box  icons  with 
a  line  thickness  of  0.  The  images  seen  on  the  screen  are  XI 1  bitmaps  that  are  defined 
as  attributes  of  the  icon  and  are  displayed  at  the  same  window  location  as  the  icon. 
Intervista  is  not  capable  of  displaying  or  manipulating  a  bitmap  by  itself,  so  the  bitmaps 
are  displayed  on  the  CW  native  window  that  underlays  the  Intervista  window.  To  use 
an  analogy,  a  CW  native  window  may  be  perceived  as  a  sheet  of  paper  and  the  INTERVISTA 
window  as  a  sheet  of  clear  transparency  film  over  the  paper.  In  normal  INTERVISTA 
operations  the  user  can  create  and  manipiilate  an  icon  on  the  treinsparency.  AVSI  II 
displays  the  bitmap  on  the  piece  of  paper  (the  CW  native  window)  at  the  same  position  as 
the  Intervista  icon.  The  overall  effect  is  an  icon-bitmap  pedr  that  renders  the  appearance 
of  a  mouse  sensitive  and  memipulatable  icon  in  INTERVISTA. 
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An  Intervista  window  has  a  predefined  attribute,  native-window,  that  holds  the 
value  of  the  underlying  CW  window.  A  bitmap  is  drawn  onto  the  native-window  using 
the  CW  command  bitblt.  Bitblt  tcikes  six  arguments:  the  bitmap-stream  to  be  drawn 
(created  with  read-bitmap  as  mentioned  above),  the  x  coordinate  of  the  origin  of  the 
bitmap,  the  y  coordinate  of  the  origin  of  the  bitmap,  the  native  window  to  draw  in,  the  x 
coordinate  of  the  point  to  draw  the  bitmap,  aind  the  y  coordinate  of  the  point  to  draw  the 
bitmap.  An  iNTERVISTA  icon’s  origin  is  defined  as  the  center  of  the  icon.  A  CW  bitmap’s 
origin  is  defined  as  the  lower  left  corner  of  the  bitmap.  The  bitmap  had  to  be  offset  from 
the  icon  position  by  half  the  x  and  y  dimensions  of  the  bitmap  in  order  to  line  them  up. 
CW  displays  the  bitmap  by  turning  on  or  off  the  appropriate  window  pixels  that  form 
the  image  on  the  screen.  Consequently,  the  bitmap  is  not  a  persistent  ajrtifax:t  and  must 
be  redrawn  whenever  a  change  or  update  to  the  INTERVISTA  window  is  made.  The  next 
subsection  discusses  the  steps  taken  to  make  the  bitmaps  appear  persistent. 

4.3.3  Refresh  and  Redraw.  Displaying  the  bitmaps  in  INTERVISTA  was  only 
the  first  step  in  putting  icon-bitmaps  into  AVSI  II.  The  INTERVISTA  manual  specifically 
mentions  the  complication  involved  with  going  outside  INTERVISTA  to  Common  Windows. 

.  .  .if  the  contents  of  a  window  needs  to  be  refreshed  .  .  .  ,  then  INTERVISTA 
will  not  know  to  redraw  any  images  that  were  drawn  in  a  native  window  by 
Common  Windows  drawing  primitives.  You  will  have  to  explicitly  specify  the 
re-drawing  operations  in  a  function  that  is  added  ....  (13) 

Several  functions  were  required  to  make  the  bitmaps  appear  persistent  and  interac¬ 
tive.  The  first  obvious  requirement  is  stated  in  the  quotation  above.  When  INTERVISTA 
refreshes  a  window,  it  erases  the  window  and  re-draws  everything  in  it.  However,  INTER¬ 
VISTA  does  not  know  how  to  execute  a  bitblt  to  redraw  the  bitmaps  in  the  native- window. 
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The  solution  implemented  involved  writing  a  new  function  that  would  enumerate  over  all 
the  icons  in  a  window,  accessing  the  bitmap  attribute  for  each  icon,  and  bitblt-ing  the 
bitmap  in  the  proper  location.  The  fimction,  called  redraw-icons,  was  added  to  INTER- 
VISTA  window’s  default  refresh  function  with  a  form  similar  to  the  one  shown  here: 

form  ADD-MY-REDRAW 

lot  (old-redrav-functions  =  ro<iraw-functioiis(*SS-WINDOW*)) 

(rodraw-functions(*SS-WINDOWo)  <-  [’rodraw-icons,  Sold-redraw-functions] ) 

The  second  issue  involved  moving  icons  in  the  windows.  Intervista  does  not  perform 
a  window  refresh  eis  a  consequence  of  moving  an  icon.  Consequently,  moving  an  icon 
resulted  in  the  appearcuice  of  the  icon  at  the  new  position  with  its  proper  bitmap  displayed, 
and  a  bitmap  still  visible  at  the  icon’s  original  position.  The  fix  was  straightforward  and 
involved  replacing  the  default  function,  user-move-icon,  with  a  call  to  a  new  function 
that  performed  user-move-icon  and  then  refreshed  the  window. 

The  last  display  issue  involved  deleting  an  icon.  Deleting  the  icon  with  the  IN¬ 
TERVISTA  delete-icon  function  does  not  refresh  the  window,  so  the  bitmap  for  the  icon 
persisted  in  the  native-window  eifter  the  icon  was  deleted.  The  fix  was  the  same  as  for 
moving  an  icon.  A  new  function  was  written  that  called  delete-icon  Eind  refreshed  the 
window. 

4.3.4  Icon  Scalability.  To  make  an  iNTERViSTA  window  and  its  contents  visible 
on  the  screen,  the  surface  viewed  by  the  window  must  be  defined  with  view-surface. 
One  action  of  view-surface  is  to  set  the  window’s  attributes  so  that  the  information 
in  the  window  is  centered  {surface-origin)  and  scaled  {scale-factor)  so  that  everything  in 
the  window  is  visible.  While  this  is  satisf2w:tory  for  icons,  the  bitmaps  drawn  by  CW  are 
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static  objects  that  cannot  be  e2isily  scsiled.  Although  an  algorithm  to  dynamically  draw  (or 
scale)  every  bitmap  using  the  CW  primitive  drawing  functions  could  have  been  developed, 
that  solution  would  have  resulted  in  severe  time  penalties  for  redrawing  screens  with  many 
icons.  It  would  also  have  necessitated  that  the  domain  modelers  be  able  to  write  drawing 
and  scaling  algorithms  for  every  primitive-object  instead  of  building  the  static  bitmaps  in 
Icon  Edit. 

The  method  implemented  for  AVSI II  was  to  restrict  the  application  specialist  to  two 
menu  selectable  icon-bitmap  sizes.  The  sizes  are  full-size  (100%)  and  half-size  (50%).  The 
domain  modeler  is  responsible  for  two  bitmaps  per  primitive-object.  This  is  considered 
to  be  a  reasonable  task.  The  specific  size  and  format  requirements  for  the  bitmaps  are 
discussed  in  Appendix  B.  Selecting  “Rescade  Window”  from  the  window  menu  calls  the 
change-scale-factor  function  that  sets  the  window’s  scale-factor  to  1.0  for  fxill-size  or  2.0 
for  half-size.  Since  the  iNTERVISTA  windows  have  scroll  bars  and  a  reshape  function,  the 
application  specialist  can  scale,  scroll,  or  reshape  ais  necessary  to  view  an  entire  application. 

4-3.5  Required  Attributes.  In  order  to  properly  display  an  icon-bitmap  pair  in  am 
Intervista  window,  the  icon  must  have  certaiin  attributes: 

•  clip-icon-label?:  Pre-defined  in  iNTERVISTA,  this  attribute  controls  whether  an  icon’s 
label  is  completely  displayed  or  tnmcated  at  the  edge  of  the  icon.  Since  the  icon  itself 
is  not  visible  in  AVSI  II,  this  attribute  should  be  set  to  false. 

•  border-thickness:  Pre-defined  in  INTERVISTA,  this  attribute  controls  the  thickness  of 
the  edge  of  the  icon.  To  make  the  icon  “invisible”  this  attribute  needs  to  be  set  to  0. 
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•  bitmap4icon-l:  An  AVSI  Il-defined  attribute,  it  stores  the  bitmap  stream  for  the 
full-size  bitmap.  The  attribute  is  defined  2is  a  map  between  an  icon  and  an  any- type. 

•  bitmap4icon-s:  An  AVSI  Il-defined  attribute,  it  stores  the  bitmap  stream  for  the 
half-size  bitmap.  The  attribute  is  defined  as  a  map  between  an  icon  and  zm  any- 
type. 

Although  there  cure  mzmy  other  attributes  of  an  icon,  the  default  values  are  sufiicient 
for  AVSI  II.  These  attributes  are  set  in  the  primitive-object’s  visual  description  file  for 
each  domain  cmd  parsed  into  AVSI  II  at  nmtime.  The  same  attributes  are  internally  set 
for  the  application-object  and  subsystem-object  icons. 

Update  Algorithm 

Four  changes  were  made  to  AVSI  in  the  update  algorithm  creation  windows.  Two 
of  them  were  cosmetic  changes  aind  two  were  functional.  The  cosmetic  changes  included 
adding  color  to  the  background  of  the  windows  and  closing  all  the  subwindows  simulta¬ 
neously.  Color  was  ^ldded  to  the  controUee  window  and  update  edgorithm  window  using 
the  process  described  in  Section  4.7.1.  Closing  all  update  windows  simultaneously  involved 
replacing  the  default  “Deactivate”  menu  command  of  window-act  ive?(w)  <-  false  with 
a  function  call  that  executes  : 

true  — >  (window-act ive?(*algorithm-window*)  <-  false; 

window-active? (*controllee-window*)  <-  false; 
window-active? (w)  <-  false) 

The  two  functional  changes  are  a  new  controllee-window  and  the  process  by  which  the 
update  algorithm  is  created.  During  the  application  composition,  subsystems  are  linked 
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to  the  application  suad  subsystems  and  primitives  are  linked  to  other  subsystems.  The 
linked  objects  are  c^dled  the  “controUees”  of  the  controlling  application  or  subsystem.  The 
existence  and  reuse  of  the  set  of  controllees  for  an  application  or  subsystem  simplified  the 
update  algorithm  definition. 

4-4-1  ControUee  Window.  The  controllee- window  is  created  in  the  s^lme  fashion 
as  all  other  diagram  windows  in  AVSI  II.  To  make  room  for  it  on  the  screen,  the  textual 
update  algorithm  window  was  moved  to  the  right  edge  of  the  screen,  and  the  controllee- 
window  was  plzured  in  the  resulting  gap.  The  display-controllees  function  creates 
the  window,  accesses  the  set  of  controllees  for  the  current  subsystem  or  application,  and 
displays  the  controllees  in  a  grid  pattern  in  the  window.  The  function  then  creates  a  pair 
of  icon-bitmaps  to  represent  if-then  and  while-do  statements  and  displays  them  in  the 
window. 

4.4-2  Update  Object  Creation.  Once  the  controUee- window  is  populated,  the 
update  algorithm  can  be  built.  When  the  mouse  is  clicked  on  a  controUee,  the  Intervista 
function  get-link  is  ccdled.  Get-link  prompts  the  application  to  select  a  Unk  by  cUcking 
the  mouse  on  a  link’s  nub.  Once  the  Unk  is  selected,  a  copy  of  the  controllee’s  icon-bitmap  is 
inserted  in  the  update  sequence,  the  icon-bitmap  is  linked  to  the  icon-bitmaps  immediately 
preceding  and  following  it  in  the  sequence,  the  originaUy  selected  Unk  is  deleted,  and  the 
textual  update  sequence  is  built  as  it  was  in  AVSI.  Once  the  update  ailgorithm  reaches 
seven  icon-bitmaps  in  length  (including  the  start  and  end  icons),  the  scale-factor  of  the 
window  is  automaticdly  set  to  2.0  for  hdf-size. 
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4-5  Import  and  Export  Areas 


The  AVSI II  changes  to  the  import-export  connection  process  were  all  additions  to 
the  prior  AVSI  capabilities.  Only  one  function  was  deleted;  some  were  modified;  and 
several  were  2idded.  AVSI  treated  the  subsystem  and  primitive  icon  groups  as  individual 
icons  and  required  a  special  function  to  move  them  as  a  group.  AVSI  II  defines  the 
import-export  icon  set  as  a  supericon  with  a  set  of  subicons.  When  a  supericon  is  moved 
with  user-move-icon  the  subicons  are  automatically  moved  to  the  appropriate  relative 
positions  from  the  supericon.  As  a  result,  the  AVSI  function  move-icon-group  bec2Lme 
unnecessary  and  was  deleted.  The  modifications  and  additions  are  discussed  below. 

4-5.1  Import  -  Export  Icon  Creation.  The  creation  of  a  subsystem  icon  is  un¬ 
changed  from  AVSI  with  the  exception  of  using  a  sub/super-icon  group  instead  of  the 
informal  icon  grouping.  The  primitive-object  icon  creation  is  somewhat  more  complicated. 
The  supericon  is  created  by  eiccessing  the  controUees  of  the  parent  subsystem  or  application 
in  the  same  fcishion  as  the  controllee- window  for  the  update  algorithm.  For  eew:h  primitive 
in  the  controllee  set,  the  domain  model  is  eiccessed  using  a  get-input-output-variable 
function.  The  frmction  returns  the  set  of  inputs  or  outputs  each  primitive  has  defined  for  it. 
The  input  sind  output  sets  are  passed,  along  with  the  supericon,  to  a  make-ie-subicons 
function.  HeJre-ie-subicons  creates  a  subicon  for  every  input  and  output,  labels  them 
appropriately,  evenly  distributes  the  input  subicons  along  the  left  edge  of  the  supericon, 
evenly  distributes  the  output  subicons  along  the  right  edge  of  the  supericon,  creates  the 
subicon-supericon  relationships,  eind  returns  the  icon  set  for  display. 
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The  method  of  populating  the  import-export  window  is  the  same  as  populating  the 
controllee-window.  The  main  difference  is  icon-bitmap  position.  If  the  attribute  comp- 
position  of  the  object  corresponding  to  the  icon-bitmap  is  defined,  the  icon-bitmap  t2d(es 
that  value  as  its  position  in  the  window.  If  the  value  is  imdefined,  the  icon-bitmap  is  passed 
to  the  make-lattice3  function  that  plztces  the  icon-bitmap  and  defines  the  comp-position 
value.  Once  the  window  is  populated  with  the  controllees,  the  connection  process  can 
begin. 

4-5.2  Primitive  Icon  Connection.  The  connections  between  primitives  was 
greatly  simplified  for  AVSI  II.  To  connect  a  specific  output  on  a  primitive  to  a  specific 
input  on  a  primitive,  the  application  specialist  simply  clicks  on  the  output  and  then  the 
input.  A  visible  link  is  created  with  link-exp-to-imp  and  the  import-export  connection 
is  made.  The  mouse  handlers  allow  the  coxmection  to  be  made  in  the  reverse  order  us¬ 
ing  link-imp-to-exp.  When  the  output  is  selected,  its  name  is  loaded  into  the  variable 
*CURRENT-EXPORT*.  When  an  input  is  selected,  the  function  checks  *CURRENT- 
EXPORT*  and,  if  it  is  defined,  a  connection  is  m^ule.  If  *CURRENT-EXPORT*  has  not 
been  defined,  the  input  is  lo2Kled  into  *CURRENT-IMPORT*,  and,  when  an  output  is 
selected,  the  connection  is  made.  If  the  peurent  subsystem’s  MSP-window(s)  are  visible 
when  the  connection  is  m2ide,  the  MSP-window(s)  are  updated.  MSP-windows  are  Mouse 
Sensitive  Printing  windows  consisting  of  mouse  sensitive  text  entries  that  correspond  to 
objects  in  the  REFINE  object  base.  In  this  instance,  the  entries  correspond  to  import  and 
export  objects. 
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The  subicon’s  highlight  state  is  used  to  feed  back  to  the  application  specialist  if  and 
where  the  import  export  is  connected.  The  three  states  (discussed  in  Section  3.2.4)  are  as 
follows: 

•  Highlighted  -  The  icon  is  displayed  in  reverse  video  by  setting  the  icon  attribute 
highlight-style  to  ’reverse-video.  This  state  represents  an  unconnected  subicon. 

•  Unhighlighted/Invisible  -  The  icon  is  not  visible  on  the  screen.  This  state  is  displayed 
by  setting  the  icon  attribute  highlight-style  to  ’unhighlighted.  The  state  represents 
an  icon  that  is  connected  to  another  icon  vbible  in  the  current  window. 

•  Thin  empty  box  -  The  icon  is  displayed  as  a  thin- walled,  empty  box.  This  state 
is  displayed  by  setting  the  icon  attribute  highlight- style  to  ’unhighlighted  and  the 
attribute  border-thickness  to  1.  The  state  represents  an  icon  that  is  connected  to 
2inother  icon  not  visible  in  the  current  window. 

If  the  application  specialist  clicks  the  mouse  on  a  link  between  icons,  he  is  given 
the  option  to  delete  or  redraw  the  link.  If  delete  is  selected,  the  visible  link  is  erased 
from  the  window,  the  import-export  connection  in  the  object  is  erjised,  and  the  MSP- 
window(8)  are  updated.  If  the  application  specieJist  selects  the  redraw  option,  the  fimction 
user-layout-link-path  is  called  and  the  link  path  can  be  memually  drawn.  The  function 
changes  the  mouse  cursor  into  em  Intervista  “pencil,”  and  the  application  specialist  can 
draw  the  path  by  moving  the  pencil  to  a  sequence  of  points  on  the  window  eind  clicking 
the  mouse  button  at  each  point  (see  Figure  4.3).  The  link  path  is  completely  drawn  when 
the  mouse  is  clicked  over  an  icon. 
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Figure  4.3  Intervista’s  Link  Pencil 


4.5.3  Inter-Subayatem  Communication.  Connecting  imports  and  exports  across 
subsystems  is  unchanged  from  AVSI’s  implementation.  The  only  difference  is  the  icon- 
bitmap  used  for  a  subsystem.  The  bitmap  was  designed  to  look  like  an  Object  Connection 
Update  (OCU)  import  area,  export  area,  controller  group.  The  bitmap  was  drawn  in 
IslandPaint  and  saved  in  XI 1  bitmap  format.  The  bitmap  is  displayed  and  updated  in  the 
window  with  the  bitblt  command  as  mentioned  in  Section  4.3.  The  icons  are  a  supericon 
(controller)  with  two  subicons. 

4.5.4  A  VS  I  Compatibility.  The  mouse  handler  and  connection  routines  were 
written  such  that  the  AVSI  process  of  making  connections  from  the  MSP-windows  is  fully 
interchangeable  with  the  new  AVSI  II  process.  By  defining  the  *CURRENT-IMPORT* 
and  *CURRENT-EXPORT*  variables  as  global  to  this  process,  the  application  speciedist 
can  connect  appropriate  text  entries  (objects)  in  the  MSP-window  with  subicons  in  the 
red  import-export-window  and  vice  versa.  Additionally,  any  addition  or  deletion  made  in 
one  window  is  immediately  reflected  in  all  other  visible  windows.  This  entire  process  was 
made  possible  by  replicating  the  code  to  connect  objects  in  MSP-windows  for  the  subicon 
connections  and  hooking  it  sdl  together  with  fimctional  converses. 


^.6  Application  Executive 


Welgan’s  research  into  providing  an  Application  Executive  capability  for  Architect 
(34)  required  the  etddition  of  menus  2uad  MSP-windows  to  AVSI  II.  The  Application  Ex¬ 
ecutive,  among  other  capabilities  not  relevant  to  this  discussion,  allows  the  application 
specialist  to  choose  execution  modes  other  th2ui  simple  sequential  updates.  The  changes 
maide  to  support  the  executive  axe  discussed  below. 

^.6.1  Execution  Mode  Support.  To  allow  Architect  to  execute  in  the  proper  mode, 
the  application  specialist  must  first  select  the  desired  execution  mode  when  the  application 
is  created.  This  was  supported  by  adding  a  single-menu  in  the  create-nes-application 
function  to  display  the  available  execution  modes  and  prompt  for  a  choice.  The  selected 
item  is  stored  as  an  attribute  of  the  application. 

Selection  of  am  event-driven  mode  obviates  the  requirement  to  build  update  algo¬ 
rithms.  The  update  algorithm  contains  the  sequence  in  which  the  primitive  objects  in  the 
application  must  update  their  state  information  so  that  data  is  propagated  through  the 
application  to  the  output  in  an  orderly  zmd  aiccurate  manner.  The  event-driven  execution 
mode  is  not  concerned  with  data  propagation;  it  is  concerned  with  event  generation  and 
processing.  To  prevent  the  application  specialist  from  wasting  time  building  an  update 
cilgorithm  that  will  not  be  used,  whenever  the  application  specialist  chooses  “Edit  Appli¬ 
cation  Update”  or  clicks  on  a  subsystem’s  controller  icon,  AVSI  II  accesses  the  application’s 
execution  mode  attribute  and,  if  it  is  an  event-driven  variant,  the  update  algorithm  func¬ 
tion  call  is  aborted  and  a  “This  Process  is  Not  Required  for  This  Application”  message  is 
displayed  in  the  AVSI  II  control  window. 
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4-6.2  Event  Queue  Support.  For  an  event-driven  execution  mode,  the  application 
specialist  needs  to  have  the  option  to  pre-load  the  event  queue,  or  modify  or  delete  items 
from  it.  When  the  application  specialist  selects  “Execute  The  Application,”  the  event 
queue  is  displayed  in  an  MSP- window.  The  window  also  displays  the  options  to  “ADD,” 
“MODIFY,  ”  or  “DELETE”  queue  entries  as  described  in  Section  3.2.5.  Adding  an  event 
is  eiccomplished  by  selecting  a  new  event-object  type  from  a  pojvup  list  of  types  and 
populating  the  attributes  of  the  object  through  a  series  of  get-string  windows.  When  all 
attributes  are  completed,  the  function  add-event  is  called  to  insert  the  event-object  in  the 
proper  location  in  the  queue.  Modifying  an  event  on  the  queue  is  accomplished  by  selecting 
the  event  to  modify,  deleting  the  selected  event,  2uid  adding  a  new  one  of  the  same  type. 
Deletion  is  accomplished  by  simply  locating  the  event-object  in  the  queue  (represented  by 
a  sequence  of  event-objects)  and  removing  it  from  the  queue. 

4.7  Miscellaneous 

4.7.1  Color  in  AVSI  II.  Since  the  current  version  of  Intervista  does  not 
provide  color  capability,  function  calls  to  CW  were  required  to  integrate  color  into  AVSI 
II.  Within  CW,  windows  and  bitmaps  au-e  defined  as  two-color  objects  (i.e.,  foregrovmd  and 
background  color).  CW  has  eight  pre-defined  colors  available:  red,  green,  blue,  magenta, 
yellow,  cyan,  black,  and  white.  Additionally,  CW  can  access  einy  named  Xll  color  or  create 
a  new  color  using  the  make-color  comm2uid.  Chapter  III  discussed  the  uses  of  color  for  the 
background  in  certain  windows.  The  color  was  losided  using  the  CW/Lisp  command  setf  ( 
cw:  :window-8tream-background-color(native-win(iow(*8s-window*)) , color)  inside  a 
form.  As  with  the  other  CW  commcinds,  this  one  changes  the  color  on  the  native-window, 
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not  the  Intervista  window.  The  difference,  however,  is  that  the  color  in  a  window  is 
persistent  because  Intervista’s  refresh  function  does  not  affect  the  background,  only  the 
foreground  of  a  window.  Because  bitmaps  are  drawn  in  the  foreground,  a  window  refresh 
affects  them. 

There  is  one  exception  to  the  statement  in  Section  3.2.2  which  mentions  that  color  was 
not  used  for  the  bitmaps.  While  bitmap-foreground  color  was  not  changed  from  black  (the 
default),  the  bzwrkground  had  to  be  changed  to  match  the  window’s  bzu:kground.  The  de¬ 
fault  bitmap-bzu:kground  color  is  white,  and  the  consequence  of  not  matching  backgrounds 
is  an  icon  in  a  small  field  of  white  on  a  colored  window.  The  bitmap  color  held  to  be  changed 
in  redraw-icons  function  using  a  commzmd  like  setf  (  (cw : :  bitmap-background-color  ( 
bitmap4icon-l  (x)  )  )  ,  bcolor) ,  where  bcolor  is  the  beu:kground  color  of  the  window  being 
refreshed. 


4-7.2  Multiple  Link  Function.  The  make-all-links  function  allows  the  ap¬ 
plication  specialist  to  link  all  the  primitive-  and  sub-subsystem-objects  to  the  current 
subsystem-object  in  one  step.  Construction  of  the  AVSI II  make-all-links  function  was 
straightforward.  When  a  subsystem-  or  application-object’s  icon  is  mouse  selected  and 
m2dse-all-links  is  selected,  the  function  first  copies  the  icons  (surf ac€-viewed(  diagram- 
window))  set  to  a  new  set.  Next  all  icons  that  are  already  connected  to  another  icon  are 
deleted  from  the  set.  The  icons  left  in  the  set  are  displayed  to  the  application  specialist  in 
a  multiple-menu.  A  multiple-menu  allows  the  user  to  select  all,  some,  or  none  of  the  entries 
in  the  list.  The  icons  selected  from  the  menu  are  stored  in  another  set  that  is  enumerated 
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over.  Each  is  automatically  linked  to  the  originally  selected  icon  with  the  same  routine 
used  in  AVSI  to  make  a  single  link. 

^.1.3  Parse  and  Save  Functions.  The  desire  to  retain  the  icon-bitmap  window 
positioning  in  the  import-export  window  required  a  change  to  both  the  Architect  archi¬ 
tectural  model  and  the  domain-specific  circhitectural  model.  Two  new  attributes  of  each 
component  object  were  created:  comp-x  records  the  x-coordinate  of  the  icon  as  a  map 
between  the  component-object  and  an  integer,  and  comp-y  records  the  y-coordinate  of  the 
icon.  A  new  attribute  of  all  component-objects  was  also  eulded  to  AVSI  II.  The  attribute, 
called  comp-position,  is  a  map  from  a  component  to  the  iNTERViSTA  type  POINT.  The 
function  get-position  converts  comp-x  and  comp-y  into  comp-position  when  a  saved  ap¬ 
plication  is  parsed  into  AVSI  II.  Conversely,  when  an  application  definition  is  saved  to  a 
file,  the  function  retrieve-position  accesses  comp-position  and  converts  the  POINT  value 
to  comp-x  and  comp-y. 

4-8  Summary 

This  chapter  outlined  the  decisions  motivating  the  design  of  AVSI  II  and  the  deteiils  of 
its  implementation.  The  goals  of  AVSI  IPs  design  were  to  enhance  the  visueJ  presentation 
«uid  interface  usability  for  an  application  specialist  building  an  application  with  Architect 
while  preserving  the  AVSI  functioneility.  The  next  chapter  describes  how  AVSI  II  was 
tested,  results  of  that  testing,  and  an  analysis  of  the  results. 
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V.  Testing  and  Validation  of  AV SI  II 


Validation  of  AVSI  II  encompassed  testing  of  two  general  categories.  The  compat¬ 
ibility  and  functionality  of  AVSI  II  were  verified  by  using  the  interface  with  applications 
constructed  prior  to  AVSI  II  development.  The  usability  of  the  interface  was  tested  via  an 
objective  analysis  of  the  reduction  in  workload  realized  through  AVSI  II  and  with  subjec¬ 
tive  evaluations  by  members  of  the  KBSE  research  group.  This  chapter  reviews  the  testing 
of  AVSI  II,  the  results  of  the  testing,  and  an  analysis  of  the  test  results.  Additionally,  an 
analysis  of  the  strengths  and  weaknesses  of  AVSI  II  is  provided. 

5.1  Validation  Domain 

AVSI  II  was  formally  tested  using  applications  developed  in  the  digital  logic-circuits 
domain.  The  interface  was  informally  tested  throughout  its  development  by  other  KBSE 
researchers  who  were  using  the  interf2ice  during  their  research.  Since  the  domain  was 
previously  validated  (1,  22,  33),  there  was  no  requirement  to  exercise  the  operation  of 
eax:h  domain  primitive;  therefore,  test  applications  were  designed  to  verify  the  interface’s 
capability,  not  the  domaun’s. 

The  test  applications  were  designed  for  and  tested  in  sequential  mode,  non-time- 
driven  execution.  This  mode  is  compatible  with  AVSI’s  capability  eind,  subsequently, 
resulted  in  a  valid  comparison  of  the  two  interfaces.  This  test  philosophy  did  not  provide 
any  indication  of  the  proper  fimction  of  time-bEjed  or  event-driven  execution  modes  of 
Architect;  however,  AVSI  II  does  not  need  to  provide  any  functionality  over  and  above 
mode  selection  and  queue  manipulation  to  support  those  modes. 
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5. 2  Compatibility  Testing 


With  the  implementation  of  specific  icon-bitmaps  for  the  domaiin  primitives,  there 
Wcis  a  need  to  verify  that  the  new  and  modified  visual  attributes  would  be  properly  created 
for  applications  developed  prior  to  AVSI II.  Four  applications  that  were  created  and  saved 
during  previous  research  v/ere  used.  Eax:h  application  was  loaded,  in  turn,  and  viewed  in 
the  edit-application-window,  the  edit-subsystem-windows,  the  update-algorithm-windows, 
and  the  import-export-windows.  The  applications  were  executed  to  verify  their  behavior, 
and  they  were  then  re-saved.  Next,  the  saved  files  were  compared  to  the  original  files  for 
consistency. 

Only  one  anomaly  was  discovered.  An  application  saved  by  Architect  does  not  con¬ 
tain  any  visual  information.  The  function  that  creates  an  icon  for  an  object  and  defines  it 
rs  a  functional  converse  for  the  object  is  executed  while  the  blue  edit-application- window 
or  edit-subsystem-window  is  populated.  Therefore,  although  the  application  load  function 
populates  the  object  base,  it  does  not  create  the  icons  and  converses.  This  requires  that  the 
edit-application-window  be  exposed,  and  thus  the  icons  and  converses  be  defined,  before 
the  update-algorithm- windows  or  import-export- windows  can  be  viewed.  Otherwise,  the 
icons  required  for  display  in  those  windows  would  not  have  been  created  yet.  It  is  impor¬ 
tant  to  note  that  since  visual  support  is  not  provided  for  execution,  the  loaded  application 
can  be  executed  without  having  to  expose  the  edit-application-window  first.  This  anomaly 
was  an  unforeseen  side-effect  of  integrating  domain-specific  graphics  into  the  update  algo¬ 
rithm  and  import-export  windows,  and  could  be  corrected  by  replicating  the  icon  creation 
function  calls  in  the  application  loading  routine. 
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Four  additioneii  test  applications  were  created  with  AVSI  II  and  subsequently  exe¬ 
cuted,  saved,  and  reloaded.  The  loaded  applications  looked  and  executed  precisely  like  the 
origincds. 

5.3  Usability  Testing 

An  objective  evaluation  of  AVSI  II’s  impact  on  the  size  of  the  application  specialist’s 
composition  effort  was  mecisured  for  four  applications.  The  data  collected  Euid  an  aneilysis 
of  the  results  eire  presented  in  the  following  subsection.  The  next  subsection  presents 
the  comments  and  evaluations  collected  from  the  other  KBSE  reseaurch  group  members. 
Two  group  members  used  AVSI  II  extensively  during  their  development  of  new  application 
domains  for  Architect  (refer  to  Section  3.3.3). 

5.3.1  User  Workload.  The  metric  developed  to  test  AVSI  II’s  usability  was 
the  number  of  user  actions  required  to  build  an  application.  Four  applications  of  varying 
complexity  were  built  with  both  AVSI  and  AVSI  II.  The  number  of  user  actions  required 
to  proceed  from  application  creation  to  execution  was  counted.  A  user  action  was  defined 
as  an  atomic  effort  (like  a  single  click  of  a  mouse  button)  or  inputting  a  value  (like  an  icon 
label).  Two  sets  of  data  were  collected  for  AVSI  II.  The  first  value,  listed  imder  the  header 
“AVSI  II,”  assumed  the  application  speciedist  was  unconcerned  with  icon  position  in  the 
import-export-windows.  These  values  represented  a  more  accurate  comparison  with  AVSI 
since  AVSI  did  not  provide  for  icon  positioning.  The  second  set  of  data,  listed  imder  the 
header  “AVSI  Il-f-,”  assumed  the  application  specialist  moved  every  icon  in  the  import- 
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Figure  5.1  Exclusive-OR  Circuit  and  Truth  Table 


Table  5.1  Exclusive-OR  Test  Results 


AVSI  II 

AVSI  Il-t- 

AVSI 

Create/Edit  Application 

15 

15 

15 

Application  Update 

7 

7 

14 

Create  Subsystems 

43 

43 

62 

Subsystem  Updates 

22 

22 

66 

Build  Imports-Exports 

36 

60 

43 

Execute 

1 

1 

1 

TOTAL 

124 

148 

201 

export- window  to  new  positions.  These  values  represented  a  truer  picture  of  AVSI  II’s  user 
worklocid  because  most  users  will  exercise  a  feature  if  it  is  available. 


5. 3. 1.1  Exclusive-OR.  The  first  test  circuit  developed  was  a  four  Nand- 
gate  implementation  of  an  Exclusive-OR  gate.  The  component  layout  and  truth  table  for 
the  circuit  are  shown  in  Figure  5.1.  Table  5.1  shows,  by  development  area  and  total,  the 
number  of  user  actions  required  to  build  the  application. 

The  data  indicate  a  39.3%  reduction  in  workload  from  AVSI  to  AVSI  II  without  icon 
repositioning,  and  a  26.4%  reduction  with  icon  repositioning  in  the  import-export- window. 
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Figure  5.2  Half  Subtr2w:ter  Circuit  and  Truth  Table 


Table  5.2  Half  Subtracter  Test  Results 


AVSI  II 

AVSI  11+ 

AVSI 

Create/Edit  Application 

15 

15 

15 

Application  Update 

7 

7 

14 

Create  Subsystems 

58 

58 

93 

Subsystem  Updates 

32 

32 

101 

Build  Imports-Exports 

44 

83 

61 

Execute 

-  -  1 

1 

1 

TOTAL 

157 

196 

285 

5.3. 1.2  Half  Subtracter.  The  second  test  circuit  developed  was  a  seven  gate 
implementation  of  a  Half  Subtreicter.  The  component  layout  and  truth-table  for  the  circuit 
are  shown  in  Figure  5.2.  Table  5.2  shows,  by  development  area  and  total,  the  number  of 
user  actions  required  to  build  the  application. 

The  data  indicate  a  44.9%  reduction  in  workload  from  AVSI  to  AVSI II  without  icon 
repositioning,  and  a  31.2%  reduction  with  icon  repositioning  in  the  import-export-window. 


5.3. 1.3  Binary  Array  Multiplier.  The  third  test  circuit  developed  was  a  fom: 
gate,  two  half-adder  implementation  of  a  Binary  Array  Multiplier.  The  component  layout 
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Figure  5.3  Binary  Array  Multiplier  Circuit  and  Truth  Table 

and  truth-table  for  the  circuit  are  shown  in  Figure  5.3.  Table  5.3  shows,  by  development 
area  and  total,  the  number  of  user  actions  required  to  build  the  application. 

The  data  indicate  a  45.0%  reduction  in  workload  from  AVSI  to  AVSI II  without  icon 
repositioning,  and  a  30.1%  reduction  with  icon  repositioning  in  the  import-export-window. 

5.3. 1.4  BCD  to  Excess-3  Decoder.  The  final  test  circuit  developed  was  an 
eleven  gate  implementation  of  a  BCD-to-Excess-3  Decoder.  The  component  layout  eind 
truth  table  for  the  circuit  are  shown  in  Figure  5.4.  Table  5.4  shows,  by  development  eu*ea 
and  total,  the  number  of  user  actions  required  to  build  the  application. 

The  data  indicate  a  46.9%  reduction  in  workload  from  AVSI  to  AVSI  II  without  icon 
repositioning,  and  a  31.7%  reduction  with  icon  repositioning  in  the  import-export- window. 
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Table  5.3  Binary  Array  Multiplier  Test  Results 


AVSI II 

AVSI  11+ 

AVSI 

Create/Edit  Application 

15 

15 

15 

Application  Update 

7 

7 

14 

Create  Subsystems 

61 

61 

102 

Subsystem  Updates 

36 

36 

115 

Build  Imports-Exports 

46 

91 

55 

Execute 

1 

1 

1 

TOTAL 

166 

211 

302 

D 


X 


■> 


BCD  :  Excess-3  code 
ABCD  wxyz 
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Figure  5.4  BCD  to  Excess-S  Decoder  Circuit  and  TVuth  Tabl^ 
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Table  5.4  BCD  to  Excess-3  Decoder  Test  Results 


AVSI  II 

AVSI  Il-h 

AVSI 

Create/Edit  Application 

15 

15 

15 

Application  Update 

7 

7 

14 

Create  Subsystems 

78 

78 

129 

Subsystem  Updates 

46 

46 

150 

Build  Imports-Exports 

62 

122 

85 

Execute 

1 

1 

1 

TOTAL 

209 

269 

394 

5.3.2  Workload  Analysts.  The  data  shows  a  significant  reduction  in  the  applica¬ 
tion  specialist’s  workload  to  build  an  application  with  AVSI  II  as  opposed  to  AVSI.  The 
average  reduction  for  the  four  applications  was  44.0%  for  applications  where  the  user  did 
not  reposition  icons  in  the  import-export-windows,  and  29.9%  for  applications  where  the 
user  did  reposition  icons  in  the  import-export-windows.  The  data  supports  a  conclusion 
that  the  percent  of  reduction  in  effort  increases  as  the  number  of  objects  in  an  applica¬ 
tion  increase  (at  leeist  for  the  option  of  nor  repositioning  icons).  The  largest  improvement 
Wcis  realized  in  building  the  update  algorithms.  The  AVSI  implementation  required  seven 
distinct  actions  to  cidd  a  single  statement  to  the  update  algorithm.  The  AVSI  II  implemen¬ 
tation  required  only  two  ^lctions,  a  71%  reduction  in  effort.  The  other  major  improvement 
arose  from  the  “Link  Multiple  Tcirgets”  feature  in  the  edit-application-window  and  edit- 
subsystem- window.  AVSI  II  allows  the  application  specialist  to  link  every  subsystem  and 
primitive  to  the  top  subsystem  with  four  user  actions  as  opposed  to  three  user  eictions  per 
subsystem  and  primitive  with  AVSI.  Lastly,  the  process  of  making  the  import-export  con¬ 
nections  was  not  overly  simplified  from  a  workload  standpoint.  With  the  addition  of  the 
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icon  positioning  capability,  this  area  became  more  workload  intensive.  The  option  exists, 
however,  to  ignore  icon  positioning  if  position  is  not  important. 

5.3.3  User  Evaluations.  The  data  presented  in  this  section  were  extracted  from 
the  comments  AVSI  II  users  and  the  responses  to  the  survey  on  AVSI  II  enhancements. 
The  informal  comments  were  centrally  recorded  throughout  the  AVSI  II  development  in 
response  to  comments  and  recommendations  from  those  KBSE  research  members  actively 
using  the  interface  in  their  research.  The  surveys  were  distributed  to  the  same  researchers 
once  AVSI  II  development  was  complete.  The  survey  contained  a  set  of  questions  concern¬ 
ing  2ispect8  of  AVSI  IPs  functionality  and  asked  if  the  chiinges  from  AVSI  represented  an 
improvement  or  degreidation  in  capability.  Each  question  zJso  had  room  for  the  rese<ircher 
to  cidd  comments  if  desired.  Listed  below  is  a  summary  of  the  comments  recorded  during 
the  interface’s  development  and  received  on  the  survey  forms. 

•  A  grid  in  the  import-export-window  would  be  helpful  in  lining  up  the  primitive  icons. 

•  Feedback  for  possible  import-export  connections  between  primitives,  similar  to  that 
provided  between  subsystems,  would  be  a  useful  feature. 

•  Another  icon  highlight  style  in  the  import-export  window  is  needed  to  show  some¬ 
thing  is  connected  to  both  visible  smd  non-visible  objects. 

•  Closing  multiple  windows  at  once  (the  update  windows  and  the  import-export  win¬ 
dows)  is  a  real  time-saver. 

•  I  like  the  “Link  Multiple  Teirgets”  option.  I  don’t  forget  to  link  ein  object  using  the 
featvire. 
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The  new  update  process  is  much  easier  to  use.  I  didn’t  like  having  to  remember  the 


names  of  ^dl  my  primitives. 

•  The  colored  windows  are  a  good  idea.  I  can  tell  which  windows  are  open  at  a  glance. 

•  The  new  icons  make  finding  a  primitive  in  the  technology  base  window  much  easier. 

One  other  comment  was  made  by  several  different  people.  They  felt  that  the  colors 
used  in  the  individusd  windows  were  irrelevant.  The  fact  that  there  was  color  and  that  the 
colors  were  different  for  different  functional  areas  was  the  significant  issue. 

The  responses  on  the  survey  were  consistent.  The  conclusions  that  can  be  drawn 
from  the  responses  are: 

1.  The  impression  of  the  application  and  subsystem  icons  was  basically  neutrzd.  Users 
felt  that  the  design  was  an  improvement  over  the  AVSI  simple-box  icon,  but  the 
specific  icon  design  was  not  anything  special. 

2.  The  Link  Multiple  Targets  function  was  seen  as  a  big  time  saver  in  the  edit- 
subsystem-window. 

3.  The  ability  to  close  multiple  windows  from  a  single  Deactivate  command  is  a  nice 
convenience. 

4.  The  abihty  to  rescale  the  icons  in  a  window  was  seen  as  an  improvement  by  most 
users,  although  one  user  felt  it  was  a  degradation  from  AVSI’s  automatic  window 
scaling. 
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5.  The  domedn-specific  icons  received  the  most  enthusiastic  feedback.  The  users  felt 
that  locating  primitive-objects  in  the  technology-base-window  was  much  easier  with 
the  icons. 

6.  The  redrawn  subsystem  diagram  window  received  an  2ilmost  unanimously  neutral 
response. 

7.  The  controllee- window  by  itself  was  not  seen  as  a  big  improvement;  however,  using 
the  controllee-window  to  populate  the  update  algorithm  sequence  was  a  significant 
improvement. 

8.  The  changes  to  the  import-export  connection  process  between  primitives  were  per¬ 
ceived  as  an  improvement.  Using  the  domain-specific  icons  in  the  window  was  a 
significant  improvement.  Icon  positioning  was  some  improvement.  The  icon  high¬ 
light  styles  were  understandable;  however,  one  user  desired  more  than  the  three 
styles  in  order  to  display  that  a  primitive  was  connected  to  both  a  visible  object  and 
a  not-visible  object. 

The  generd  impression  of  the  users  of  AVSI  II  was  that  the  visual  enhancements 
to  the  interface  were  a  greater  improvement  to  the  system  than  the  usability  enhance¬ 
ments  were.  The  usability  enhancements  were  a  time  savings,  though;  especially  the  Link 
Multiple  Targets  and  redesigned  update  algorithm  composition  processes. 

5-4  A  VSI  IPs  Shortcomings 

The  visud  enhancements  of  AVSI  II  euid  the  increased  usability  of  the  interface  2u-e 
signific^lnt  eiccomplishments.  However,  there  is  dways  a  new  feature  or  a  better  layout 
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for  miy  display.  The  evolutionary  development  of  Architect  requires  that  the  graphical 
interface  also  evolve  to  incorporate  new  functionality.  The  following  areas  of  AVSI  II  still 
require  significeuit  research: 

1.  Support  for  the  Architect  Application  Executive.  AVSI  II  provides  only  rudimentary 
support  for  the  power  of  the  Executive.  The  application  specialist  must  be  given 
the  capability  to  interface  with  and  possibly  configure  the  Application  Executive 
function  for  Architect.  Initially,  Architect  and  AVSI  II  were  designed  to  support 
a  sequential  update  execution  mode.  Time-driven  sequential  execution  modes  amd 
event-driven  execution  modes  are  under  development  to  support  a  vairiety  of  domains. 
More  application  specialist  control  over  the  event  queue  before,  during,  and  aifter 
execution  will  be  required  to  support  the  new  modes.  For  time-driven  domains,  a 
system  clock  will  be  required  ais  paxt  of  the  Application  Executive.  Additionally,  the 
time  relevauit  information  should  be  displayed  to  the  application  specialist. 

2.  Visual  support  for  semantic  analysis.  This  area  was  identified  as  a  shortcoming  for 
AVSI;  the  deficiency  persists  into  AVSI  II.  Semantic  anaJysis  is  reflected  in  AVSI  II  3is 
a  simple  “Semantic  checks  passed”  message  or  a  failure  message  with  instructions  to 
look  at  the  Emeics  window  for  deteiils.  The  semantic  functions  of  Architect  should  be 
strengthened  to  accurately  report  the  specific  semantic  violation  and  AVSI  II  should 
have  the  capability  to  present  the  erroneous  design  area  in  a  user  editable  window 
with  the  specific  error  highlighted. 

3.  Visual  support  for  application  execution.  This  was  also  identified  as  a  shortcoming  of 
AVSI.  AVSI  II  was  not  intended  to  solve  this  shortcoming,  but  execution  visualization 
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is  a  logical  extension  of  the  interface.  Using  the  concepts  developed  for  AVSI II,  ein 
object’s  state  could  be  displayed  using  color,  highlighting,  or  movement.  Color  and 
highlight  style  eure  maintained  as  attributes  of  an  icon,  and  an  icon  is  maintained 
as  a  fimctional  converse  of  an  object.  The  state  of  an  object  is  simply  an  attribute 
or  collection  of  attributes  of  the  object.  Therefore,  it  is  a  straight-forward  task  to 
monitor  the  state  of  an  object  by  checking  its  attributes,  and  set  or  modify  the 
values  of  the  corresponding  icon’s  color  or  highlight  style  attributes.  The  location 
of  an  icon  in  a  window  is  stored  as  an  attribute  called  position  which  is  of  type 
POINT.  Movement  of  cm  icon  can  be  simulated  by  repeatedly  re-drawing  the  icon 
(and  bitmap)  at  a  sequence  of  positions.  The  speed  at  which  the  icon  is  redrawn 
and  the  distance  between  successive  points  will  determine  how  smooth  the  movement 
appears. 

5. 5  Summary 

The  concepts  applied  to  this  reseeurch,  and  summarized  in  Chapter  II,  have  shown 
that  a  sophisticated  graphic2il  interface  can  be  developed  to  support  a  visual  composition 
process.  AVSI  II  was  a  positive  step  in  enhjmcing  the  interface  to  Architect.  The  ca¬ 
pability  to  display  emd  manipulate  dommn-specific  icons  makes  designing  an  application 
more  intuitive  for  the  application  speciadist.  The  bitmaps  and  colors  increased  the  applica¬ 
tion  specisdists  ability  to  find  primitive-objects  in  the  various  windows  and  to  immediately 
recognize  in  which  window  he  is  working.  The  revised  processes  for  building  the  update 
algorithms  for  sequential  execution  appUcations  and  the  expanded  visualizations  for  the 
import-export  connection  processes  reduce  the  user’s  workloawi  and  reduce  the  possibility 
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of  error  from  misnamed  update  objects  or  improper  connections.  AVSI  II  proved  to  be 
fully  compatible  with  previously  designed  applications,  thus  preserAdng  the  efforts  of  earlier 
research.  This  chapter  reviewed  the  process  by  which  AVSI  II  was  tested  eind  validated. 
Also,  it  summarized  the  feedback  on  the  interface’s  usabihty  from  users  of  the  system. 
Some  of  AVSI  II’s  shortcomings  were  mentioned.  Those  shortcomings,  as  well  as  some  of 
the  user  feedback  comments,  axe  juidressed  in  more  detail  in  the  next  chapter. 
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VI.  Conclusion  and  Recommendations 


The  original  goals  for  developing  the  AVSI II  visucil  interface,  as  discussed  in  Chapter 
I,  were  to  enhcince  the  graphiced  presentation  and  usability  of  the  interface  to  Architect, 
a  domain-oriented  application  composition  and  generation  system.  The  existing  graphical 
interface  for  Architect,  AVSI,  was  developed  in  Intervista  and  sulfered  from  a  limited 
range  of  graphical  display  options.  AVSI  II  overccime  the  display  limitations  by  augmenting 
Intervista ’s  graphics  with  cidditional  functionality  provided  by  Common  Windows,  a 
graphical  development  package  for  Lisp  and  the  graphical  foundation  for  INTERVISTA. 
The  specific  design  goals  stated  in  Chapter  I  are: 

1.  Develop  a  set  of  domain-specific  graphical  icons  (metaphors)  for  an  existing  Architect 
application  domain  and  integrate  the  graphics  into  AVSI  II’s  application  construction 
process. 

2.  Develop  the  means  for  domedn  engineers  to  develop  and  incorporate  additional  iconic 
metaphor  sets  for  new  application  domains. 

3.  Redesign  the  update  algorithm  definition  process  to  eliminate  duplication  of  effort 
and  tedium. 

4.  Redesign  the  import/export  connection  process  by  exploiting  domain-specific  graph¬ 
ics  to  make  object  connection  more  intuitive. 

5.  Support  the  visualization  needs  of  concurrent  research  activities. 

6.  Test  the  new  interface  and  quantify  AVSI  IPs  improvement  in  the  areas  of  usability 
and  composition  effort  reduction. 
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6.1  Results  and  Conclusions 


AVSI  II  successfully  zurhieved  the  original  research  goals.  Design  euid  development 
were  conducted  through  rapid  prototyping  and  incremental  improvement.  This  philosophy 
proved  to  be  highly  successful.  The  Softw2ire  Refinery^^  development  environment  of 
Refine  and  Intervista  was  well  suited  for  prototyping  based  on  its  transformational 
capabilities.  Each  step  in  the  research  built  upon  e2u:lier  accomplishments  zmd  extended 
the  capability  of  AVSI  II.  Achievement  of  the  four  goads  can  be  summarized  in  three  areas 
of  activity: 

6.1.1  Domain-Specific  Graphics.  Use  of  domain-specific  bitmaps  mauie  specific 
primitive-objects  in  the  technology-base-window  reaidily  identifiable.  The  application  spe¬ 
cialist  does  not  have  to  rely  on  the  object  class  naimes  to  differentiate  between  the  prim¬ 
itives.  The  graphics  also  made  locating  specific  objects  in  am  application  easier  by  first 
focusing  the  application  specialist’s  attention  on  the  type  of  primitive-object  amd  then 
letting  the  icon  label  identify  the  specific  object. 

The  design  rules  amd  concepts  by  which  the  metaphors  and  bitmaps  for  the  logic- 
circuits  domain  were  developed  for  AVSI  II  was  generalized  into  a  process  that  can  be 
applied  by  any  domaiin  engineer  or  domadn  modeller  to  a  new  domaun  development.  The 
process  is  delineated  in  Appendix  B.  Using  the  steps  in  Appendix  B,  Warner  successfully 
developed  a  set  of  metaphors  and  bitmaps  for  the  Digitail  Signal  Processing  (DSP)  domain 
(32),  and  Waggoner  developed  a  set  of  metaphors  amd  bitmaps  for  the  cruise  missile  domaiin 
(31). 
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Color  backgrounds  were  integrated  into  several  AVSI II  windows.  Color  proved  to  be 
a  powerful  context  cue  for  users  of  the  interface.  Color  was  not  integrated  into  the  design 
of  individutil  icons  in  AVSI  II,  primarily  because  of  the  two  color  limitation  of  the  XI 1 
bitmap  format  used  with  Common  Windows;  however,  Section  6.2  discusses  some  potential 
research  in  the  area  of  icon  color. 

6.1.2  Update  Algorithm.  The  integration  of  icon-bitmaps  into  AVSI  II  provided 
a  significantly  wider  range  of  application  design  options.  The  greatest  success  in  AVSI  II’s 
usability  enhancement  was  recilized  in  constructing  the  update  algorithm  for  the  application 
and  its  subsystems.  Creation  of  the  controllee-window  alleviated  the  user  from  the  need 
to  remember  the  nzimes  of  the  objects  being  added  to  an  update.  The  process  of  clicking 
on  the  controllee  icon  and  “dropping”  it  in  the  update  sequence  significantly  reduced  the 
effort  required  to  build  the  update  algorithm. 

6.1.3  Import-Export  Areas.  Integrating  domain-specific  graphics  into  the  import- 
export  connection  process  was  a  challenge  in  visualization.  Constructing  the  import-export 
connections  for  primitives  within  a  subsystem  emulates  the  process  of  “hooking  up”  a 
system.  This  process  fits  a  user’s  concept  of  reality  and  is  easy  to  comprehend.  The  process 
of  connecting  objects  in  one  import/export  area  to  an  object  in  other  export/import  cireEis 
remains  an  OCU-like  abstraction  and,  therefore,  is  a  straightforward  concept  to  assimilate. 
However,  connecting  a  primitive’s  inputs  or  outputs  to  imports  or  exports  in  the  MSP- 
window  of  another  subsystem  does  not  fit  any  previous  conceptual  models,  but  the  process 
is  imcomplicated,  and  a  user  can  eeeily  adapt  to  it.  There  is  a  concern  that  the  multiple 
possible  ways  to  make  connections  (i.e.,  icon  to  MSP-window  object,  MSP-window  object 
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to  icon,  MSP-window  object  to  MSP-window  object,  and  icon  to  icon)  within  the  same  set 
of  windows  could  present  too  mwy  options  for  a  user. 

6.2  Recommendations  for  Further  Research 

1.  Explore  color  use  or  highlight  styles  in  bitmaps.  The  two  color  limitation  of  the 
Common  Windows/Xll  bitmap  format  and  a  desire  to  keep  the  bitmap  develop¬ 
ment  simple  resulted  in  the  use  of  only  black  icons  in  AVSI  II.  There  are  drawing 
capabilities  in  Common  Windows  that  extend  beyond  simply  “bitblt-ing”  a  bitmap 
to  a  window.  Additionally,  tapping  the  functionality  of  CLX  or  X  Windows  itself 
sh  ‘Id  be  explored. 

A.  ERVlSTA  has  the  capability  to  accept  user  defined  icon  types.  The  process  of 
defining  an  icon  type  effectively  requires  the  programmer  to  write  a  mini-progrcim  of 
instructions  to  Intervista  detailing  how  the  icon  can  be  drawn  md  manipulated. 
Assuming  an  Architect  dommn-specific  icon  type  can  be  developed,  it  would  solve 
the  problems  of  icon  scedability  that  currently  restrict  AVSI  II  to  either  h^df-size 
or  full-size.  Additionally,  INTERVISTA  has  sm  tmdocumented  icon  type  defined  as 
BITMAP.  The  BITMAP  type  is  not  supported  in  the  current  version  of  INTERVISTA; 
however,  it  is  possible  that  future  releases  of  the  software  will  support  the  icon  type. 

Intervista  currently  supports  two  highlight  styles:  unhighlighted  or  reverse-video. 
New  highlight  styles  can  be  defined  in  the  same  fashion  that  new  icon  styles  can  be 
defined.  The  use  of  grays  or  cross-hatches  as  alternative  highlight  styles  would  give 
the  interface  developer  more  flexibility  in  communicating  with  the  user. 
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2.  Explore  the  use  of  sounds  in  the  interface.  By  making  LISP  cedis  to  the  host  operat¬ 
ing  system,  an  interface  developer  can  incorporate  sounds  into  the  interface  design. 
Sotmds  are  a  common  part  of  user  interface  design,  and,  although  easy  to  misuse 
or  abuse,  soimd  can  provide  strong  reinforcement  or  feedback  to  a  user.  Computers 
typicedly  beep  at  a  user  if  an  error  occurs,  or  chime  upon  successful  completion  of  a 
task. 

3.  Extend  user  feedback  in  the  controllee-window.  The  controllee-window  in  AVSI  II 
provides  no  visual  feedback  as  to  which  controllees  have  been  incorporated  into  the 
update  algorithm  (other  than  visual  inspection  of  the  textucd  edgorithm  window). 
Although  this  is  not  a  problem  for  a  simple  sequenticd  update,  when  If-Then  or  While- 
Do  statements  are  being  constructed,  the  user  may  wish  to  know  which  controllees 
have  or  have  not  been  used.  One  potentied  solution  would  be  to  change  the  color  of 
the  icon  in  the  controllee-window  once  it  has  been  used  in  the  update  somewhere,  or 
to  highlight  the  icon  in  some  other  fashion. 

4.  Develop  a  structured  process  for  If-Then  and  While- Do  condition  statements.  When 
developing  an  If-Then  sequence  or  While-Do  loop  in  AVSI  II,  the  construction  of  Then 
and  Do  statement  sequences  is  adequately  supported.  The  If  and  While  conditions, 
however,  have  minimed  visual  support.  The  condition  statements  should  refer  to  data 
values  derived  from  the  data  in  the  current  subsystem’s  import  or  export  aurea.  With 
the  current  process,  the  conditions  do  not  have  to  correspond  to  export  data  values, 
even  though  they  should,  and  the  application  specialist’s  discipline  is  the  only  factor 
preventing  nonsensical  data  from  being  used  as  a  condition. 
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5.  Refine  the  import-export  connection  process.  Much  work  remains  to  be  done  in  the 
import-export  connection  process.  Several  of  the  user  feedback  comments  mentioned 
in  Section  5.3.3  should  be  considered  for  incorporation  into  AVSI II.  The  most  notable 
of  the  suggestions  concerns  the  icon  alignment  grid.  The  suggestion  to  display  po- 
tentieJ  connections  between  primitives,  similar  to  what  is  done  between  subsystems, 
also  warrants  consideration.  However,  the  danger  exists  that  the  line  density  on  the 
screen  could  be  intrusive  when  several  primitives  with  multiple  inputs  or  outputs  2ure 
involved. 

6.  Extend  support  for  the  Application  Executive.  The  Application  Executive  is  a  new 
feature  of  Architect  which  was  simultaneously  being  developed  with  this  research 
(34).  Due  to  the  concurrent  development  of  the  Application  Executive  and  AVSI  II, 
AVSI  II  has  only  rudimentary  support  for  the  application  specialist  to  interface  with 
the  Application  Executive  capabilities.  Architect’s  interface  needs  to  be  extended  to 
fully  support  all  modes  aind  operations  of  the  Application  Executive. 

7.  Provide  visual  support  for  semantic  checks.  As  mentioned  in  the  previous  chapter, 
AVSI  II  does  not  directly  support  semantic  an^dysis  of  an  application.  A  possible 
feature  to  incorporate  into  the  interface  would  be  context-sensitive,  editable  text  win¬ 
dows  that  display  the  erroneous  code  and  either  allow  the  application  specialist  to  fix 
the  code  in  the  window,  or  indicate  where  the  error  should  be  fixed  by  modifications 
to  the  icons  and  links. 

8.  Incorporate  visualization  of  application  execution.  This  item  is  a  significant  topic 
in  its  own  right.  The  application  execution  can  be  visualized  in  ways  as  simple 
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as  changing  the  color  or  highlight  styles  of  icons  as  their  states  change  or  displaying 
alternative  bitmaps  for  differing  object  states.  The  visualization  could  be  as  complex 
^is  partial  to  full  animation  of  the  application  as  it  executes. 

9.  Investigate  Single  Window  Composition.  The  application  composition  process  in¬ 
volves  four  different  windows  in  which  a  different  aspect  of  the  application  definition 
is  conducted.  The  windows  are  the  Edit-Application-Window,  the  Edit-Subsystem- 
Windows,  the  Edit-Update-Windows,  and  the  Import-Export-Windows  (however, 
event-driven  or  time-driven  modes  do  not  utilize  the  edit-update- windows).  Consid¬ 
eration  should  be  given  to  adapting  AVSI II  into  a  single,  or  perhaps  dual,  window 
composition  system.  Although  such  a  system  would  deviate  firom  the  OCU-model 
abstr2u:tion,  it  would  be  simpler  and  potentially  more  intuitive  for  the  application 
specialist  to  use.  Conceptually,  such  a  process  would  have  the  application  special¬ 
ist  create  and  neime  an  application  or  application-object.  Then  the  specialist  would 
insteintiate  objects  from  the  technology  bEise  and  populate  a  subsystem-composition- 
window.  The  objects  would  then  be  connected  to  eswrh  other  in  the  manner  of  AVSI 
II’s  import-export  connection  process  of  defining  the  objects’  sources  and  teurgets. 
These  connections  cem  replace  the  need  to  connect  objects  to  a  controlling  subsys¬ 
tem  since  the  controlling  subsystem  can  be  identified  by  creating  a  mapping  between 
the  composition  window  and  the  subsystem-object.  The  update  algorithm  can  be  at 
least  partially  inferred  from  the  import-export  connection  order  given  that  a  set  of 
conventions  (like  left  to  right  data  fiow)  are  enforced.  The  connection  order  could 
be  used  to  automatically  create  a  partial  dependency  graph  or  table.  Additioned 
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inferencing  about  the  application  or  application  specialist  inputs  would  be  used  to 


complete  the  dependency  graph. 

6.3  Summary 

Development  of  a  visual  interface  is  not  an  exact  science.  Much  of  the  design  effort 
is  spent  developing  a  system  that  “looks  good,”  “works  well,”  or  “seems  easy”  to  use. 
These  concepts  are  difficult  to  explain  and  ever  harder  to  quantify.  “Looks  good,”  for 
example,  means  different  things  to  different  people  in  different  situations.  For  this  type  of 
reseeurch,  rapid  prototyping  was  the  most  effective  design  method  avsdlable.  Incremental 
development  of  the  interface  capabilities  helped  quimtify  AVSI  IPs  design  by  zdlowing  other 
users  to  use  and  comment  on  the  interface  as  it  was  evolving. 

The  role  of  application  composition  and  generation  systems  like  Architect  is  increas¬ 
ing  in  importance  within  the  software  industry.  One  of  the  keys  to  the  successful  develop¬ 
ment  of  systems  like  Architect  is  aa  understandable  and  usable  interf^K:e.  AVSI  II  extended 
Architect’s  usability  by  incorporating  sophisticated  graphics  {uid  an  improved  application 
development  processes.  As  mentioned  in  this  chapter,  there  is  a  significant  amount  of 
rese2u:ch  remaining  for  the  development  of  an  AVSI  III  or  beyond.  The  interfeK:e  developer 
will  be  a  key  member  of  any  application  composer  development  team. 
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Appendix  A.  Sample  Session  for  AVSI II 


This  appendix  contains  a  sample  session  in  which  a  BCD  to  Excess-3  Decoder  is  built 
from  the  primitive  objects  defined  in  the  logic-circuits  domain.  The  circuit  diagram  for 
the  Decoder  is  shown  in  Figure  A.l. 


Figure  A.l  BCD  to  Excess-3  Decoder  Circuit 


A.l  Starting  AVSI 

Refine  must  be  loaded  in  the  Emacs  window  from  the  Architect  directory.  Once 
this  is  accomplished  enter: 

(load  "1") 

When  the  prompt  returns,  enter: 

(1) 
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It  will  take  several  minutes  for  this  file  to  run  because  it  lo2«ls  the  DIALECT  and  Intervista 


systems  as  well  as  the  Architect  and  AVSI  II  files.  When  the  load  is  complete,  a  prompt 
appears: 

Load  Complete 

Type  "(AVSI)"  to  start  AVSI 
Now  enter  the  commamd: 

(avsi) 

This  action  loads  the  visual  specification  files  for  the  domains  currently  defined  for 
Architect.  After  the  visual  information  is  parsed  into  the  object  base,  the  control  panel 
(shown  in  Figure  A.2)  appeairs  in  the  upper  left-hand  comer  of  the  screen.  Across  the 
top  of  the  window  is  a  row  of  buttons  that  are  used  to  invoke  many  of  the  application 
composition  functions  of  AVSI  II.  The  lower  portion  of  the  window  is  a  message  area  used 
to  display  status  and  errors. 
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A. 2  Create  a  New  Application 
To  create  a  new  application: 

1.  Click  any  mouse  button  on  the  button  labeled  Create  New  Application. 

2.  A  pop-up  window  appears  2ind  prompts,  Select  Domain.  Click  on  the  menu  item 
CIRCUITS. 

3.  A  pop-up  window  appecirs  with  the  prompt,  Enter  name  of  application.  Type 
bcd-xs3 

4.  The  name  can  be  entered  by  hitting  the  “return”  key  or  by  clicking  on  Do  It  at  the 
bottom  of  the  pop-up  window. 

A. 3  Edit  the  Application 

Now  that  the  application  has  been  created,  the  next  step  is  to  edit  the  application’s 
elements.  Editing  an  application  is  comprised  of  two  separate  operations:  editing  Ein 
application’s  components,  and  editing  aa  application’s  update  eJgorithm. 

A. 3.1  To  add  a  controlling  subsystem-obj  to  the  application: 

1.  Click  a  mouse  button  on  the  Edit  Application  control  panel  button. 

2.  A  pop-up  menu  appeeus  with  the  prompt  Choose  Application.  Click  on  the  menu 
item  BCD-XS3. 

3.  A  pop-up  menu  appears  with  the  prompt  Choose:  Click  on  the  menu  item  Edit  Ap¬ 
plication  Components.  A  blue  window  appeeus  containing  a  single  icon  labeled, 

APPLICATION  -  OBJ  ^  3) 
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Figure  A.3  Edit-Application-Window 

4.  Click  on  the  diagrcun  surface  (anywhere  on  the  blue  surface  except  within  the  icon’s 
bouridary)  of  the  window.  A  pop-up  menu  will  appear. 

5.  Select  Create  New  Subsystem. 

6.  A  pop-up  window  appears,  with  the  prompt  Enter  a  name:.  Enter  driver 

7.  A  box  outline  of  an  icon  appears,  attached  to  the  mouse  cursor.  Pl2u:e  the  icon  below 
the  application-obj  icon  by  moving  the  cursor  to  the  desired  location  and  clicking. 

8.  CUck  any  mouse  button  on  the  newly  created  subsystem-obj  icon  and  select  the  menu 
option  Link  to  Source. 

9.  The  mouse  cursor  cheuiges  from  an  arrow  to  an  oval  with  a  dot  in  it,  signifying  that 
an  object  needs  to  be  selected.  Place  the  mouse  cursor  on  the  application-obj ’s  icon 
Eind  click  any  mouse  button.  A  link  appears  between  the  application-obj ’s  icon  and 
the  subsystem-obj ’s  icon,  as  in  Figure  A.4. 
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Figure  A.4  Edit-Application-Window 

10.  Close  the  edit-application-window  by  clicking  on  the  diagram  surface  cind  selecting 
Deactivate. 

A. 3.2  To  create  the  application-obj’s  update- (dgorithm: 

1.  Click  a  mouse  button  on  the  Edit  Application  control  panel  button. 

2.  A  pop-up  menu  appears  with  the  prompt  Choose  Application.  Click  on  the  menu 
item  BCD-XS3. 

3.  A  pop-up  menu  appears  with  the  prompt  Choose;.  Click  on  the  menu  item  Edit 
Application  Update.  Three  windows  will  appear  (refer  to  Figure  A.5).  One  con¬ 
tains  a  graphical  view  of  the  update  algorithm,  one  contMns  a  textual  view  of  the 
Eilgorithm,  and  the  third  (the  Controllee  Window)  shows  the  icons  that  represent 
the  application-obj’s  controllees  (with  two  extra  icons  for  if-then  and  while-do  con- 
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structs).  The  graphical  update  window  contains  two  icons,  “Start”  and  “End,”  with 
a  dotted  arrow  pointing  from  the  start-icon  to  the  end-icon. 


4.  Click  a  mouse  button  on  the  icon  in  the  controllee  window  labeled  obj 

DRIVER 

The  cursor  changes  to  an  oval  with  a  dot  in  it  indicating  that  an  object  needs  to  be 
selected. 

5.  Click  on  the  “nub”  on  the  dotted  line  midway  between  the  start  and  end  icons. 
This  will  cause  the  update  sequence  to  redraw  with  the  subsystem-obj  included  (  see 
Figiure  A.6).  Note  the  textual  representation  is  automatically  updated  to  reflect  each 
change  in  the  diagram  window. 


6.  Close  the  edit-update-algorithm  windows  by  clicking  on  the  black  title  bar  at  the  top 
of  the  graphical  update  window  and  selecting  Deactivate. 

A. 4  Edit  the  Subsystems 

Building  a  subsystem  is  similar  to  building  the  application.  This  section  illustrates 
instantiating  and  linking  primitive-objs  zuid  a  nested  subsystem-obj  to  the  controlling 
subsystem  created  in  the  previous  section. 

A-7 


Figure  A.7  Subsystem  Window 


The  subsystem,  DRIVER,  will  control  four  switches,  four  LEDS,  and  a  separate 
subsystem  (called  bcd-excessS),  which  is  the  heart  of  the  application.  Bcd-excessS  consists 
of  three  not-gates,  four  and-gates,  ^lnd  four  or-gates  (refer  beu:k  to  Figure  A.l).  To  add 
these  objects,  perform  the  following  steps: 

A. 4-1  To  add  the  subsystem: 

1.  Click  on  the  Edit  Subsystem  button  in  the  control  pwel  window. 

2.  Click  on  the  menu  item  DRIVER.  A  white  window  opens  (the  subsystem  window) 
which  contains  2ui  OCU  representation  of  a  subsystem  (see  figure  A.7). 

3.  Click  on  the  Objects  icon  in  the  subsystem  window.  The  blue  edit-subsystem- 

window  for  DRIVER  appears,  contedning  a  single  icon  labeled  , 
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Figure  A.8  Edit-Subsystem  and  Technology-Base  Windows 


A.9 


A  green  window,  the  technology-base  window,  adso  appears  and  contains  an  icon  for 
eeich  primitive-object  in  the  current  domain  (see  figure  A.8). 

4.  Click  on  the  blue  diagram  surface  and  select  the  Create  New  Subsystem  menu 
item. 

5.  Name  the  new  subsystem  bcd-excess3. 

6.  PlEice  the  subsystem-icon  somewhere  on  the  blue  window. 

A. 4. 2  To  add  the  primitive  objects: 

1.  Click  on  the  icon  in  the  green  technology-base- window  labeled  SWITCH-OBJ,  that 
looks  like  a  toggle  switch. 

2.  A  Switch-icon  is  created  and  attached  to  the  mouse  cursor.  Place  this  icon  on  in  the 
blue  edit-subsystem-window  near  DRIVER. 

3.  Name  the  switch  by  typing  A  in  the  pop-up  window. 

4.  Follow  the  above  steps  to  create  and  place  three  more  switch  objects,  named  B,  C, 
emd  D. 

5.  Similaxily,  create  four  LED  objects  neuned  W,  X,  Y,  and  Z. 

6.  Link  the  primitive  objects  £ind  BCD-EXCESS3  to  DRIVER  by  clicking  a  mouse 
button  on  DRIVER,  amd  selecting  Link  Multiple  Targets  firom  the  pop-up  menu. 

7.  A  pop-up  window  will  appear  that  lists  all  the  unconnected  objects  in  the  edit- 
subsystem- window.  Select  All  of  the  Above,  and  click  on  Do  It.  A  link  will  appear 
from  DRIVER  to  each  of  the  other  icons.  Figure  A. 9  shows  the  edit-subsystem- 
window  at  this  point. 
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Figure  A. 9  Edit-Subsystem- Window 


8.  Now  click  on  the  technology-base-window  icon  that  represents  a  not-gate. 

9.  Position  it  near  BCD-EXCESS3  and  click  a  mouse  button  to  “drop”  it. 

10.  Name  the  not-gate  by  typing  notl  in  the  pop-up  window. 

11.  Repeat  the  process  to  add  not2  and  not3. 

12.  Select  the  the  appropriate  icons  from  the  technology-base- window  and  create  andl, 
and2,  and3,  and4,  orl,  or2,  or3,  and  or4. 

13.  Link  the  new  primitive  objects  to  BCD-EXCESS3  by  clicking  a  mouse  button  on 
BCD-EXCESS3,  and  selecting  Link  Multiple  Teurgets  from  the  pop-up  menu. 
Select  All  of  the  Above,  emd  click  on  Do  It. 

Note:  The  window  is  probably  cluttered  and  disorganized  at  this  point.  You  can  clean 
up  the  display  by  clicking  on  the  blue  background  of  the  edit-subsystem-window  and 
selecting  Redraw.  The  window  is  redi  .iwn  in  an  inverted  tree-layout  with  DRIVER 
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at  the  root  and  the  other  objects  arranged  underneath.  The  entire  subsystem  will 
not  be  visible  in  the  window.  You  can  scroll  the  window  vertically  or  horizontally 
using  the  scroll-bars  on  the  left  and  bottom  of  the  window.  The  window  can  be 
resized  by  clicking  the  mouse  on  the  black  title  bar  and  selecting  Reshape.  You 
can  eilso  change  the  size  of  the  icons  in  the  window  by  clicking  on  the  blue  surface 
and  selecting  Change  Scale  Factor  from  the  menu.  A  new  window  will  appear 
prompting  Pull  Size  (1:1)  or  Half  Size  (1:2).  Select  half  size  and  the  window  will 
be  redrawn  with  the  icons  at  half  scale.  You  may,  at  any  time,  pretty-print  an  object 
(show  its  object  base  representation)  by  clicking  on  its  icon  and  choosing  the  menu 
selection  Pretty-Print  Object. 

14.  Close  the  edit-subsystem-window  and  the  technology-base-window  by  clicking  on  the 
blue  surface  and  selecting  Deactivate.  The  windows  can  be  closed  separately  by 
selecting  Deactivate  from  their  title  bsur  menus. 

At  this  point,  the  subsystem  window  for  DRIVER  will  agetin  be  visible. 

A. 4. 5  To  connect  DRIVER’S  Imports  and  Exports:  To  connect  the  import  2md 
export  objects  perform  the  following  steps: 

1.  Click  a  mouse  button  on  the  Import  Area  or  Export  Area  icon  in  DRIVER’S 
subsystem  window. 

2.  Select  Make  Connections  from  the  pop-up  window.  A  red  window  (the  import- 
export- window)  will  open  and  contain  the  four  switch  icons,  the  foiu:  led  icons,  and 
an  OCU-like  icon  representing  the  BCD-EXCESS3  subsystem  (as  shown  in  Fig¬ 
ure  A.  10).  The  black  bars  (these  bars  are  actually  highlighted  subicons  attached 
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to  the  primitive’s  icon)  on  the  sides  of  the  primitive  icons  indicate  connections  that 
need  to  be  made. 


3.  Icons  can  be  moved  to  new  positions  on  the  screen  by  clicking  on  the  icon  and  selecting 
Move  Icon  from  the  pop-up  menu.  An  square  grid,  attached  to  the  mouse,  appears. 
Move  the  grid  to  the  new  icon  position  and  click  to  “drop”  the  icon.  An  example  of 
the  repositioned  icons  is  shown  in  Figure  A.ll. 

4.  Click  on  the  part  of  BCD>EXCESS3’s  icon  labeled  Import  Area.  A  white  text 
window  (a  msp-window)  will  appear  in  the  upper  right  area  of  the  screen.  The 
window  lists  the  objects  in  BCD-EXCESS3  that  require  input  (see  Figure  A.12). 

5.  Connect  Switch  A  to  gate  OR4  by  clicking  the  mouse  on  the  black  bar  on  A  and 
then  clicking  on  the  text  entry  IN2  SIGNAX  OR4  in  the  msp-window.  Notice  that 
the  black  bar  changes  to  a  clear  box  (indicating  the  switch  is  connected  to  an  object 
not  visible  on  the  screen),  the  msp-window  is  updated  to  reflect  the  connection. 
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Figure  A.ll  Repositioned  Icons 
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Figure  A. 12  Import  Area  for  BCD-EXCESS3 


and  another  msp- window  labeled  “Export  Area  for  DRIVER”  appears.  The  export 
window  shows  the  same  connections  being  made  from  the  switch’s  perspective. 


6.  In  the  szune  fashion,  m2ike  the  following  connections; 


switch  B 
switch  B 
switch  B 
switch  C 
switch  C 
switch  D 
switch  D 
switch  D 


connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 


INI  NOT2 
IN2  AND2 
IN2  AND4 
IN2  ANDl 
IN2  ORl 
INI  NOTl 
INI  ANDl 
INI  ORl 


In  a  similar  manner,  the  leds  must  be  coimected. 


7.  Click  on  the  part  of  BCD-EXCESSS’s  icon  labeled  Export  Area.  A  white  text 
window  (a  msp- window)  will  appear  in  the  lower  right  area  of  the  screen.  The  window 
lists  the  objects  in  BCD-EXCESS3  that  provide  output. 

8.  Connect  Led  W  to  gate  OR4  by  clicking  the  mouse  on  the  black  bar  on  W  and 
then  clicking  on  the  text  entry  OUTl  SIGNAL  OR4  in  the  msi>-window.  Again, 
the  black  bar  changes  to  a  clear  box  (indicating  the  led  is  connected  to  an  object 
not  visible  on  the  screen),  the  msp- window  is  updated  to  reflect  the  connection, 
and  another  msp-window  labeled  “Import  Area  for  DRIVER”  appeeirs.  The  import 
window  shows  the  ssune  connections  being  made  from  the  led’s  perspective. 

9.  In  the  same  fashion,  make  the  following  connections: 

led  X  connected  to  OUTl  OR3 
led  Y  connected  to  OUTl  OR2 
led  Z  connected  to  OUTl  NOTl 
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Figtire  A. 13  DRIVER’S  Import-Export  Window 


When  the  connections  have  been  made,  the  import-export-window  should  look  some¬ 
thing  like  Figure  A. 13  and  BCD-EXCESS3’s  msp-windows  should  look  like  Fig¬ 
ure  A. 14. 

10.  Close  the  import-export-window  and  the  msp-windows  by  clicking  on  the  red  surface 
2uid  selecting  Deactivate,  or  by  selecting  Deactivate  from  each  window’s  title  beu* 
menu. 

7b  6ut/d  DRIVER 's  Update  Algorithm:  After  the  import-export  windows 
have  been  closed,  the  white  subsystem  window  will  again  be  visible.  Building  the  update 
adgorithm  for  DRIVER  is  simil2u:  to  building  the  update  algorithm  for  the  application, 
zmd  requires  the  following  steps: 

1.  Click  the  mouse  on  the  Controller  icon  in  the  subsystem  window.  The  three  win¬ 
dows  that  were  seen  in  Figure  A.5  2ure  exposed,  except  the  controllee  window  now 
contsdns  the  switches,  leds,  and  subsystem  controlled  by  DRIVER. 
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Figure  A. 14  Import-Export  MSP-Windows 
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2.  Add  each  controllee  to  the  update  sequence  by  clicking  on  the  controUee  icon  emd 
then  clicking  on  the  “nub”  in  the  graphical  update  window  that  represents  the  proper 
sequence  position  for  the  controUee.  The  order  in  which  the  controUees  must  appear 
is: 

A  B  C  D  BCD-EXCESS3  W  X  Y  Z 

When  the  fifth  icon  is  eidded  to  the  sequence,  the  window  wiU  automatically  resize  to 
keep  the  entire  sequence  visible.  Figure  A. 15  shows  the  completed  update  algorithm. 
Note  that  the  textual  update  description  is  updated  as  the  graphical  update  is  built. 

3.  Close  the  windows  by  cUcking  on  the  graphical  update  window  title  bar  and  selecting 
Deactivate. 

A. 4-5  To  connect  BCD-EXCESS3 ’s  Imports  and  Exports:  So  far,  the  appli¬ 

cation  has  been  created,  the  controUing  subsystem  (DRIVER)  has  been  created,  zuid 
driver’s  components,  import-export  connections,  and  update  algorithm  have  been 
defined.  The  definition  process  for  DRIVER  now  needs  to  be  repeated  for  BCD- 
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Figure  A. 16  BCD-EXCESS3’s  Import-Export  Window 

EXCESS3.  Begin  by  defining  BCD-EXCESS3’s  import-export  connections  in  the  fol¬ 
lowing  way: 


1.  Click  a  mouse  button  on  the  Edit  Subsystem  button  on  the  control  peuiel. 

2.  Select  BCD-EXCESS3  from  the  pop-up  window.  A  subsystem  window  will  open. 
This  window  correspondes  to  BCD-EXCESS3,  as  indicated  by  the  window  title. 
Although  the  BCD-EXCESS3’s  components  were  defined  in  Section  A. 4.2,  they 
can  be  viewed  by  clicking  on  the  subsystem’s  Objects  icon.  The  windows  are  closed 
by  clicking  on  the  blue  surface  and  selecting  Deactivate. 

3.  Open  the  import-export- window  by  clicking  the  mouse  on  the  Import  Area  or 
Export  Area  icon  and  selecting  Make  Connections  from  the  pop-up  window. 
The  import-export- window  will  look  like  Figure  A.  16.  As  with  the  earlier  import- 
export-window,  the  black  bars  (again,  actually  subicons)  represent  connections  to  be 
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Figure  A. 17  BCD-£XCESS3’s  Import-Export  Window 

made,  and  the  clear  boxes  (also  subicons)  represent  connections  made  to  objects  not 
visible  in  the  window. 

4.  Reposition  the  icons  to  resemble  the  circuit  diagra’n  in  Figure  A.l.  The  icors  are 
repositioned  by  clicking  on  the  icon,  selecting  Move  Icon  from  the  pop-up  menu, 
moving  the  grid  to  the  desired  location,  and  clicking  to  “drop”  the  icon.  The  repo¬ 
sitioned  icons  will  probably  look  something  like  Figure  A.  17. 

5.  Connect  ANDl  to  OR2  by  clicking  on  the  black  bar  labeled  OUTl  on  ANDl  eind 
then  clicking  on  the  black  bcir  labeled  INI  on  OR2.  Note  that  a  line  (a  link)  appears 
between  the  icons  zmd  the  bl2w:k  beurs  disappear.  The  subicons  of  the  primitives  are 
still  present,  and  are  highlighted  by  a  thin  white  line  when  the  mouse  is  over  one. 

6.  Make  the  remetining  connections  described  below: 
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Figure  A. 18  BCD-EXCESS3’s  Import-Export  Window 


ANDl OUTl 
ORl  OUTl 
ORl  OUTl 
ORl  OUTl 
NOT2  OUTl 
NOT3  OUTl 
NOT3  OUTl 
AND2  OUTl 
AND3  OUTl 
AND4  OUTl 


connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 
connected  to 


OR2  INI 
NOT3  INI 
AND3  mi 
AND4  INI 
AND3  IN2 
OR2  IN2 
AND2  INI 
OR3  mi 
OR3m2 
OR4  mi 


Once  the  connections  have 


been  made,  the  import-export  window  should  resemble 


Figure  A. 18.  If  desired,  the  links,  once  made,  can  be  “hand-drawn”  by  clicking  on 
the  link’s  nub  and  selecting  Re-Draw  Path.  The  existing  link  will  be  deleted,  the 
mouse  cursor  will  change  to  a  “pencil,”  and  a  dashed  line  will  connect  the  icon  to  the 


cursor.  Draw  the  link  by  moving  the  cursor  to  a  new  position  and  clicking  the  mouse 
button.  To  finish  drawing  the  link,  click  the  mouse  button  on  a  subicon.  Also,  if  you 
find  the  labels  on  the  subicons  intrusive,  they  can  be  suppressed  by  clicking  on  the 


window  surface  and  selecting  Clip  Icon  Labels  from  the  pop-up  menu. 
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7.  Close  the  import-export-window  by  clicking  on  the  red  surface  and  selecting  Deac¬ 
tivate  from  the  menu. 

A. 4-6  To  build  BCD-EXCESS3 ’s  Update  Algorithm:  When  the  import-export- 
window  closes,  the  subsystem  window  will  be  visible.  To  build  the  update  algorithm  for 
BCD-EXCESS3  do  the  following: 

1.  Click  the  mouse  on  the  Controller  icon  u  the  subsystem  window.  The  three  update 
windows  will  be  exposed,  and  the  controllee  window  will  contain  the  controUees 
defined  for  BCD-EXCESS3. 

2.  Create  the  update  sequence  by  clicking  the  mouse  on  an  icon  in  the  controllee  window 
and  then  clicking  on  the  nub  in  the  graphiced  update  window  as  was  done  with  the 
application  and  DRIVER  update  algorithms.  Add  the  controUees  to  the  update 
edgorithm  in  the  following  sequence: 

NOTl  ANDl  ORl  N0T2  N0T3  0R2  AND2  AND3  AND4  0R3  0R4 


The  completed  sequence  is  shown  in  Figure  A.19. 
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IVibie  A.l  BCD  to  Excess-S  Decoder  TVuth  Table 
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3.  Close  the  update  windows  by  selecting  Deactivate  from  the  title  bar  menu  of  the 
graphical  update  window. 


A. 5  Perform  Semantic  Checks 

Sememtic  checks  are  performed  by  Architect  as  peirt  of  the  import-export  connection 
process.  However,  the  sememtic  checks  may  be  run  at  any  time  by  clicking  on  the  control 
pauiel  button  labeled  Check  Semantics.  The  results  of  the  semantic  checks  may  be  viewed 
in  the  EMACS  window. 


A. 6  Execute  the  Application 

Now  that  the  application  has  been  fully  defined,  it  can  be  executed.  The  truth  table 
for  the  BCD-XS3  decoder  is  shown  in  Table  A.l. 

The  default  position  for  a  switch  is  “on,”  however  1  1  1  1  is  not  a  defined  input  for  a 
BCD  to  Excess3  Decoder.  Therefore,  the  switch  attributes  have  to  be  set  to  a  meemingful 
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input  in  order  to  get  a  vidid  output  from  the  execution.  To  set  the  switch  attributes,  do 
the  following: 

1.  Click  on  the  control  panel’s  Edit  Sul^ystem  button. 

2.  Choose  DRIVER  from  the  pop-up  window. 

3.  Click  on  the  Objects  icon  in  the  subsystem  window. 

4.  Click  on  the  switch  icon  labeled  A. 

5.  Choose  View/Eklit  attributes  from  the  pop-up  window.  A  window  appears,  listing 
the  switch  attributes  for  A. 

6.  Click  on  the  attribute.  Position.  A  pop-up  window  appears,  listing  the  current  value 
of  the  switch. 

7.  Enter  a  new  value  for  the  switch  position  by  typing 
avsi: :off 

(The  “avsi::”  prefix  is  the  package  name  and  is  required  for  symbols.  It  is  not 
required  for  other  data  types  such  as  numbers  and  strings) 

8.  Change  the  values  for  any  other  switches  in  the  same  manner  eis  above. 

Changing  the  switch  settings  can  also  be  accomplished  in  the  edit-application-window 
by  clicking  ov  the  Edit  Application  control  pstnel  button,  selecting  BCD-XS3  from  the 
list,  selecting  Edit  Application  Components  from  the  menu,  and  then  making  the 
attribute  chEuiges  as  described  above.  Opening  the  edit-application- window  will  Edse  allow 
you  to  see  the  entire  application  in  tree-layout  format.  Window  reshaping  Emd  icon  resizing 
will  be  necessEuy  to  view  the  entire  application.  Figure  A.20  shows  the  application. 
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Once  a  valid  input  state  has  been  achieved,  click  on  the  control  panel  button  labeled 
Execute  Application.  The  results  are  displayed  in  the  EMACS  window.  A  new  set  of 
switch  positions  can  be  established,  and  the  application  re-executed. 
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Figure  A.20  BCD-XS3  Application 
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Appendix  B.  Instructions  for  Developing  a  Metaphor  Set 


This  appendix  contains  information  that  a  domain  modeller  or  domain  engineer  will 
find  useful  when  developing  a  new  domain  for  Architect.  The  following  sections  discuss 
some  design  considerations  to  be  used  in  determining  icon  metaphors  for  domain  primitive 
objects,  as  well  as  detailed  instructions  about  the  naming  conventions  and  file  requirements 
for  the  Architect  Visual  System  Interfsure  (AVSI)  II. 

B.l  Design  Principles 

Webster’s  New  Collegiate  Dictionary  defines  an  icon  as  “a  usually  pictorial  repre¬ 
sentation:  IMAGE”  (19).  Although  icons  are  frequently  associated  with  religious  imagery, 
an  icon  is,  in  f2w:t,  any  picture  or  symbol  used  to  represent  einother  object,  idea,  or  ac¬ 
tion.  Icons  have  infiltrated  almost  every  aspect  of  our  daily  lives,  especially  as  a  result 
of  attempts  to  communicate  across  the  barriers  of  language.  Icons  should  convey  precise 
messages  simply  through  their  shape  or  picture;  any  accompanying  text  is  usually  unnec- 
esseuy.  This  capability  to  convey  me2ming  is  reflective  of  Arend’s  concept  of  a  “globzd 
superiority”  visual  effect  (2).  The  globed  superiority  effect  ^tsserts  that  global  features  like 
shape,  size,  and  color  csui  be  recognized  2md  assimilated  faster  than  features  like  lines  and 
text.  In  other  words,  simple  pictures  with  one  or  two  distinctive  features  make  effective 
icons.  Nan  Shu  also  endorses  the  use  of  icons  by  stating  (25): 

•  Pictures  eu'e  more  powerful  than  words  as  a  means  of  communication  because  they 
convey  more  meaning  in  a  more  concise  unit  of  expression. 

•  Pictures  sdd  comprehension  wd  remembering. 
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•  Pictures  typiczdly  do  not  have  language  barriers.  Properly  designed  pictures  are 
understood  by  people  regardless  of  their  native  language. 

The  primary  goal  of  a  Graphical  User  Interface  (GUI)  is  to  increase  human  produc¬ 
tivity  and  speed,  *«id  to  reduce  human  error  and  fatigue.  In  Human- Computer  Interface 
Design  Guidelines,  Brown  notes  that  appropriately  applied  icons  and  symbob,  directly 
manipulatable  by  a  user  in  ways  analogous  to  reality,  can  help  the  user  maintain  context 
2md  orientation  and  reduce  the  user’s  need  to  memorize  commands  and  syntzoc.  More 
importantly,  looking  at  and  working  with  pictures  b  more  fun  than  working  with  a  screen 
full  of  text.  Icons  can  be  more  effective  than  text  because  they  can  convey  a  large  amoimt 
of  information  in  little  space,  they  are  easily  learned  and  easily  remembered,  and  they 
are  more  universal  (3).  The  icons  and  symbob  on  a  dbplay  are  frequently  referred  to  as 
metaphors  because  of  the  designed  intention  of  using  them  to  represent  a  piece  of  reality 
in  an  abstr2K;t  way.  The  icon  or  metaphor  b  a  vbued  representation  of  a  command,  task, 
method,  file,  object,  etc.  The  first  challenge  in  GUI  design  is,  therefore,  to  develop  a  set 
of  metaphors  appropriate  to  the  domun  of  interest. 

Determining  what  metaphor  to  use  as  an  icon  can  be  difiicvilt.  The  key  to  developing 
a  useful  metaphor  is  to  exploit  a  user’s  knowledge  of  familieur  objects  in  a  domeun.  Erickson 
recommends  looking  at  a  system’s  functionality  for  clues.  He  says  to  “note  what  metaphors 
are  alre2uiy  implicit  in  the  problem  description  [domain]”  because  people  commonly  use 
metaphors  when  talking  about  abstract  concepts,  and  “it’s  almost  certain  that  metaphors 
are  lurking  about  in  the  description  of  the  [system’s]  fimctionality”  (9:69). 
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authors  have  attempted  to  describe  what  constitutes  a  good  icon  design.  Deb¬ 
orah  Mayhew  recommends  the  following  (18:316-330): 

•  Minimize  semantic  and  articulatory  distance, 

•  Provide  visual  feedback  for  icon  position,  selection,  imd  movement, 

•  Choose  a  consistent  icon  scheme, 

•  Design  icons  to  be  concrete  and  familiar, 

•  Design  icons  in  a  set  to  be  visually  and  conceptv  ally  distinct, 

•  Avoid  excessive  detail  in  icon  design, 

•  Accompany  icons  with  names, 

•  Limit  the  number  of  icon  types  to  12  if  possible,  but  at  most  20. 

Semantic  distance  is  the  subjective  or  psychological  distance  between  the  user’s  in¬ 
tended  action  on  an  icon  and  the  operations  allowed  by  the  interface  to  be  performed 
on  the  icon.  Semantic  distance  directly  applies  to  the  level  of  abstraction  represented  by 
the  GUI.  Articulatory  distance  refers  to  the  relationship  between  an  icon’s  shape  and  its 
meaning.  For  example,  representing  a  Nand-gate  with  an  icon  that  looks  like  a  basebsdl 
imposes  a  large  articulatory  distance  on  the  metaphor. 

Ben  Shneiderm2m  recommends  many  of  the  same  guidelines,  but  adds  that  the  de¬ 
signer  should  (24:210): 

•  Mzdce  the  icon  stand  out  from  its  background, 

•  Ensure  the  hsumoniousness  of  each  icon  as  a  member  of  a  family  of  icons. 
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Mayhew’s  fifth  guideline  (i.e.,  design  icons  in  a  set  to  be  distinct)  and  Shneiderman’s 
second  guideline  (i.e.,  ensure  the  harmony  of  each  icon  in  a  family)  relate  well.  Within  a 
specific  domain  (or  set  or  family)  every  icon  must  be  distinct  and  recognizable  from  every 
other  icon,  but  they  must  all  relate  to  the  overall  domain.  A  paintbrxish  would  be  out  of 
place  in  a  logic-circuits  domedn,  for  example. 

Carroll,  Mack,  and  Kellogg  state  that  developing  a  set  of  interface  metaphors,  or 
icons,  is  an  iterative  process  that  is  refined  over  time.  They  claim  the  first  step  in  creating 
a  metaphor  set  is  to  generate  a  set  of  candidate  metaphors  and  develop  them  using  these 
ingredients: 

•  User’s  experiences  with  other  systems  or  situations  similar  to  the  system  being  de¬ 
signed, 

•  User’s  knowledge,  perceptions,  «md  motivations, 

•  Sheer  invention. 

They  further  emphasize  that  they  know  of  no  formal  aneilysis  method  for  generating  useful 
metaphors  (6). 

Chang  goes  a  step  further  by  recommending  a  strategy  for  creating  visud  represen¬ 
tations  of  objects.  He  recommends  considering  the  following  f^lctors  (7:69-70): 

•  Application  and  Cultur2d  Dependence:  Icons  typic^dly  represent  a  class  of  objects 
rather  tham  one  specific  instamce.  Avoid  excessive  detaul  amd  reflect  the  semamtic 
nature  of  am  object. 
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•  Easy  Recognition:  An  icon  should  have  a  precise  meaning  that  is  easily  recognized 
once  identified.  Icons  do  not  have  to  be  read,  and  people  typically  do  not  read  words 
they  are  familiar  with  anyway  (Note:  This  does  not  preclude  icon  labels).  There  are 
more  distinctively  shaped  pictures  than  words. 

•  Distinction  From  Other  Icons  Within  the  System:  An  icon  must  be  individually 
distinctive  and  should  use  a  distingmshing  feature  to  reflect  the  meaning  it  represents. 

•  Consistency  in  an  Environment:  Although  icons  should  be  distinctive,  they  should 
be  consistent  and  harmonious  within  a  system  or  domain. 

Erickson  describes  a  process  for  generating  interface  metaphors  which  consists  of  the 
following  fundzimental  steps  (9:68-72): 

•  Determine  Functional  Definition:  It  is  necessary  to  imderstand  something  in  order  to 
develop  a  model/metaphor  for  it.  This  includes  what  it  looks  like,  how  it  functions, 
and  what  its  semantic  behavior  is. 

•  Identify  User’s  Problems:  Figure  out  what  information  about  an  object  is  important 
to  a  user  amd  incorporate  the  information  into  the  icon. 

•  Generate  Metaphors:  Note  what  metaphors  are  already  implicit  in  the  problem  (or 
domain)  description.  Using  previously  identified  metaphors  can  aid  recognition  of 
the  icon. 

•  Evaluate  Interface  Metaphors:  Once  the  metaphors  have  been  developed,  evaluate 
their  accuracy  amd  effectiveness  through  aictuad  use.  Allow  users  to  provide  feedbau;k 
on  the  icon  design. 
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Developing  the  proper  metaphors  to  represent  the  primitive  objects  of  a  specific 
domain  requires  the  domain  modeller  or  engineer  to  have  extensive  knowledge  of  the  domain 
and  of  the  people  who  will  be  interacting  with  the  domain. 

B.2  Bitmap  Construction 

B.2.1  Available  Tools.  Once  the  metaphors  have  been  developed,  the  next  step  is 
to  create  bitmaps  to  “visualize"  the  metaphors.  The  actual  icons  (bitmaps)  for  a  domain’s 
primitives  can  be  developed  using  Icon  Editor,  an  OpenWindows^^  tool,  or  any  paint 
program  capable  of  generating  an  Xll  Bitmap  format  file.  Figure  B.l  shows  the  Icon 
Editor  tool,  and  the  drawing  tools  associated  with  it.  The  program  has  a  small  window 
that  shows  the  icon  at  it’s  actual  size,  and  a  large  window  where  a  pixel  by  pixel  edit  of  the 
icon  can  be  accomplished.  Make  sure  the  “B&W”  button  is  selected  and  that  the  format  is 
“X  bitmap.”  The  format  is  set  from  the  “Format”  submenu  imder  the  “Properties”  menu. 

B.2. 2  Required  Sizes.  AVSI II  currently  supports  two  display  sizes  for  the  objects 
in  a  window.  Full-sized  (the  default)  icons  2u:e  displayed  using  a  64x64  pixel  bitmap.  Hiilf- 
sized  icons  are  displayed  using  a  32x32  pixel  bitmap.  The  “Size”  submenu  under  the 
“Properties”  menu  is  were  the  size  is  set.  EsM^h  primitive  must  have  a  leurge,  or  full-sized, 
and  a  small,  or  half-sized,  bitmap  file  created.  Using  sizes  other  than  64x64  and  32x32  is 
not  recommended  because  the  AVSI  II  window  refresh  functions  expect  bitmaps  of  those 
sizes  and  will  not  draw  other  sized  bitmaps  in  the  proper  location.  The  next  section 
discusses  the  naming  conventions  used  for  the  bitmap  files  and  how  to  decl2ure  which  files 
contain  what  bitmaps  to  AVSI  II. 
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B.3  File  Creation 


B.3.1  <bitmap>-/.  This  is  the  recommended  neuning  style  for  the  full-sized 
(64x64  pixel)  bitmap.  If  the  file  has  been  properly  created,  the  file  header  will  look  similcir 
to  this  and-gate  example: 


tdefine  andgate. icon_vidth  64 
tdefine  andgate.icon.height  64 
static  char  andgate . icon_bits []  =  ■( 


B.3. 2  <bitmap>-s.  This  is  the  recommended  naming  style  for  the  hEdf-sized 
(32x32  pixel)  bitmap.  If  the  file  has  been  properly  created,  the  file  header  will  look  similar 
to  this  and-gate  example: 


tdefine  andgate. icon-s.width  32 
tdefine  emdgate. icon-s_height  32 
static  char  €mdgate.icon-s_bits[]  =  { 

B.3. 3  t/ar-<domeun> .  This  file  conteiins  the  function  call  that  reads  a  bitmap  file 
from  the  system  and  assigns  a  variable  name  to  represent  the  bitmap-stream  (the  actual 
internal  graphic)  that  is  created.  The  relative  path  and  complete  filename  must  appear 
in  the  quotation  marks.  The  UNIX  file  system  is  case  sensitive,  so  the  filename  must  be 
exact.  The  declairations  for  the  emd-gate  primitive  eure  given  as  an  example: 


var  and-bitmap-1  :  2my-type  =  (cw: : read-bitmap ( 

" . /CIRCUITS-TECH-BASE/andgate . icon-1") ) 
vau:  and-bitmap-s  :  any-type  =  (cw; : read-bitmap ( 

" . /CIRCUITS-TECH-BASE/andgate. icon-s") ) 


Note  that  there  are  two  declarations  for  the  and-gate;  one  for  the  large  and  one  for 
the  small  bitmaps. 

B.3.4  vs/-<domain> .  This  file  declares  the  user  editable  attributes  and  icon 
attributes  for  each  primitive  object  in  the  domjun.  The  relevant  entries  in  this  file  are  the 
bitmap4icon-l  and  bitmap4icon-s  lines.  The  entries  on  the  right  side  of  the  “=”  must 
exactly  match  the  variable  names  declcired  in  the  wr-<domain>  file  discussed  above.  The 
vsl-<domam>  entries  for  the  and-gate  are  shown  below. 


attributes  for  And-Gate-Obj  are 
Icon  : 

label  s  class-and-name ; 
clip-icon-label?  »  false; 
border-thickness  =  0; 
bitmap4icon-l  «  and-bitmap-1; 
bitmap4icon-s  =  and-bitmap-s 
Edit  : 

name  :  symbol ; 
delay  :  integer; 
meuiuf acturer  :  string; 
mil-spec?  :  boolean; 
power-level  :  real 

end; 


B.4  Conclusion 

The  task  of  drawing  the  bitmaps  and  integrating  them  into  AVSI II  is  not  compli¬ 
cated.  The  real  challenge  to  the  domain  modeller  or  engineer  is  to  develop  a  set  of  useful 
and  meaningful  metaphors  to  represent  the  primitive  objects. 
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Appendix  C.  A  General  Collection  of  AVSI II  Metaphors 


This  appendix  presents  a  set  of  general  purpose  icons.  Each  bitmap  pair  is  saved  in 
files  with  the  name  of  the  icon  zmd  a  -1  or  -s  sufiSx  for  large  (64x64  pixel)  or  small  (32x32 
pixel)  size,  respectively.  Each  pair  is  followed  by  a  short  description  of  the  intended  or 
possible  metaphors  inherent  in  the  shape.  The  bitmaps  were  constructed  using  the  process 
described  in  Appendix  B.  All  bitmaps  are  available  in  the  “generic-icons”  subdirectory  of 
the  Architect  directory. 


axis.icon  :  This  bitmap  is  a  three  dimensional  coordinate  aods.  The  metaphor  could 
represent  a  physical  plot,  a  spatial  relationship,  or  a  volume. 


book.icon  :  This  bitmap  is  an  open  book.  The  possible  metaphors  represented  are  ref¬ 
erence  material,  information  or  help,  a  source  of  data,  or  a  collection  of  processed  data. 


bulb.icon  :  This  bitmap  is  a  light  bulb.  Ttaditionedly  a  metaphor  for  an  idea,  this  icon 
could  3ilso  represent  a  light  source  or  a  new  concept. 
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calculator,  icon  :  This  bitmap  is  a  calculator.  The  metaphor  can  represent  einy  mathe¬ 
matical,  financial,  or  statistical  manipulation. 


clock.icon  :  This  bitmap  is  a  clock.  The  metaphor  can  represent  the  passage  of  time,  a 
deadline,  or  an  appointment/meeting/rendezvous. 


combine.icon  :  This  icon’s  metaphor  is  the  combination  of  two  things.  Possibilities  for 
using  the  icon  include  combining  data,  fluid  flows,  air  flows,  or  other  objects. 


G 

Einu 


o 

a 


disk.icon  :  This  icon  is  a  disk.  Its  metaphor  represents  storage  of  data,  tremsportation  of 
data,  or  an  external  source  of  data. 


process.icon  :  This  bitmap’s  metaphor  can  represent  any  process  (generic,  specific,  ab¬ 
stract,  or  concrete)  where  something  is  taken  in,  possibly  manipulated  ,  2md  output. 
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hourglass.icon  :  This  icon  is  an  hourglass.  Similar  to  the  clock,  this  metaphor  can 
represent  the  passage  of  time,  but  on  a  smaller  scede.  It  can  also  represent  a  visible 
p£tssage  of  time  -  meaning  slowness. 

MEASURE 


measure.icon  :  This  bitmap  is  a  ruler.  It  can  represent  length,  distzmce,  size,  or  some 
other  physical  measurement. 


printer.icon  :  This  bitmap  is  a  printer.  The  metaphoric  representation  is  data  output. 


retrieve,  icon  :  This  bitmap  is  a  piece  of  paper  being  removed  from  a  folder.  It  represents 
data  or  information  retrieval.  It  also  implies  the  retrieval  is  of  small  amounts  of  data  from 
a  nearby  or  local  source. 


split.icon  :  This  bitmap  is  a  companion  to  combine.icon.  It  represents  the  division  of 
some  item  into  parts. 
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store,  icon  :  This  bitmap  is  a  companion  to  retrieve.  The  metaphor  represents  the  saving 
or  storage  of  information. 


terminal.icon  :  This  bitmap  is  a  computer  terminal  or  monitor.  The  metaphor  represents 
the  display  of  information  or  data;  or  a  visual  output  source. 


-  — 

1 - r 

TOOLS 

0 

SSSi 


toolkit.icon  :  This  bitmap  is  a  tool-box.  It  can  represent  a  variety  of  programming, 
design,  or  construction  aids,  utilities,  or  tools. 

In  addition  to  the  bitmaps  shown  above,  there  is  a  wide  variety  of  two-  and  three- 
dimensional  geometric  shapes  that  can  be  used  as  metaphors.  Examples  include  rectangles, 
boxes,  circles,  diamonds,  triangles,  cubes,  3ind  spheres. 
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Appendix  D.  Refine  Code  Listings  for  A  VSI II 

This  appendix  conteuns  a  listing  of  the  Lisp  files  required  to  run  Architect  and  AVSI 
II.  The  order  in  which  the  files  are  listed  below  also  indicates  the  required  compilation 
order. 


%  Load  system  files  for  Dialect  and  Intervista 

(load-system  "dialect"  "1-0") 

(load-system  "intervista"  "1-0") 

(load  "AVSI-pkg.fasU") 

'/,  Load  Architect  files 

(in-package  ’AVSI) 

( load  "DSL/ lisp-ut il it ies . f  a8l4” ) 

(load  "OCU-dm/dm-ocu.faslA") 

(load  "OCU-dm/gram-ocu.faslA") 

(load  "DSL/global8.fa8l4") 

(load  "DSL/ob j -ut ilit ies . f a8l4" ) 

(load  "DSL/read-utilities. fa8l4") 

(load  "DSL/menu. fa8l4") 

(load  "DSL/display-files. fasl4") 

(load  "DSL/modify-obj.fasl4") 

(load  "DSL/save. fa8l4") 

(load  "DSL/generic. fasl4") 

(load  "DSL/build-generic .fasl4") 

(load  "DSL/complete. fasl4") 

(load  "DSL/set-globals.fasl4") 

(load  "OCU/ import 8-export 8 . f asl4") 

(load  "0CU/de8criptor-tools.fa8l4") 

(load  "0CU/eval-expr.fa8l4") 

(load  "□CU/execute.fasl4") 

(load  "OCU/semantic-checks .fa8l4") 

(load  "lisp-file-utils. fasl4") 

y.  Load  AVSI  II  files 
(load  "V8l-dm.fa8l4") 
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(load  "▼sl-gr.fuli") 

(load  ‘'Yal'-globala.fasl4'') 

(load  ''V8l~util8.1a8l4'*) 

(load  "viz~util8.fa8l4'') 

(load  ''8dit-8zpra88ion.fa8l4"} 

(load  "8dit-updat8.fa8l4”) 

(load  "edit-attr.fa8l4") 

(load  "creata-obj .fa8l4") 

(load  ''8dit-88.faal4") 

(load  "edit-applic.la8l4") 

(load  "tech-ba8a.fa8l4") 

(load  "inp-‘8zp.fa8l4'') 

(load  "te8t-priiiiitive.fa8l4") 

(load  "app-«Z8.fa8l4'') 

(load  "viz.fa8l4") 

(load  "AVSI.faaU") 

X  Load  Application  Domain-Specific  Filaa  Hare 

) 


The  Refine  source  code  for  AVSI II  may  be  obtained,  upon  request,  from: 


Maj  Paul  B2ulor 
AFIT/ENG 
2950  P  Street 

Wright-Patterson  AFB,  OH  45433-7765 

(513)255-9263 
DSN  785-9263 
email:  pbailor@afit.af.mil 
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